Deblocking filter for JPEG/digital video

Thanks M; received.

The methods you implemented were indeed computationally costly, and so
I can see where Jack Berlin's comments were directed. UnBlock takes
nowhere near that amount of computational complexity. As noted in an
earlier posting, the computational cost of UnBlock is comparable
(factor of two or three) to that of converting colorspaces and back
again. We're talking maybe half a dozen integer additions per pixel.

Thanks
John

Good question, Michel. My apologies that, right now, I don't have
figures for you in that form.

Jack Berlin, in his post, says that UnBlock achieves better PSNR
performance than Pegasus's deblocking filters, so that provides a form
of benchmark. If you are looking at the maximum JPEG achievable
compression ratios for the same quality, then I guess one would use
Pegasus's compressor (which optimizes the compression, as far as I can
tell), and then replace their deblocking filter with UnBlock.

I have not yet done this form of analysis, but will post figures when I
do.

John

Sorry, Bill, I took another look at your files in cacreeks.com/unblock,
and I now realise why they looked strange.

You've saved the results of your comparisons back in JPEG format, which
confounds them completely, because they have picked up new artifacts in
the recompression. What's worse, you've saved them with a high degree
of compression (possibly similar to that of the original image). I was
only able to replicate the file sizes by pushing the compression
quality to a very low level. This makes the files of no use (although
what you saw on the PSP screen may have been fine).

For example, if I open twinsOrig.jpg in UnBlock, the results look
completely different than what you show in twinsUnblk.jpg; in fact,
twinsUnblk.jpg looks much more like twinsOrig.jpg than it does the
output of UnBlock. (In fact, I couldn't replicate it at all using the
software I was using here, but I'm not using PSP.)

UnBlock only lets you save results in BMP format, to avoid any second
round of compression artifacts, to avoid any ambiguities in viewing the
results (e.g. if your viewer had its own deblocking and other filters,
as some seem to do), and to allow the chrominance channels to be
represented faithfully. For posting on my website, I converted to PNG
for the same reason (but to squash them down a little).

With regards to my comments about ringing, the twins image seems to
have suffered particularly badly, especially where the highly textured
rocks background has "jangled" the DCT and bled the textures over onto
the skin areas. As noted, UnBlock doesn't remove ringing as such,
although in some cases it can make the edges of it a little less
jarring. (I'll be coming back to the ringing issue separately.)

Thanks for taking the time to help out,
John

John Costella wrote:

> I'd appreciate it if you could post some images somewhere (or send them
> to me) showing examples of the staircasing and vertical lines.

I like black and white Lena, it has some artifacts few postprocessors 
can effectively deal with. A random version off the net :

http://www.irisa.fr/temics/Equipe/Chappelier/owavelets/full/0.25/lena.jpg

The staircasing occurs mainly on the edge of her right cheek, although 
theres some bad spots between the mirror and it's frame too. Her left 
eye suffers too. The vertical lines appear on her arm and left cheek.

Marco

In comp.compression John Costella <jpcostella@hotmail.com> wrote:
> Sorry, Bill, I took another look at your files in cacreeks.com/unblock,
> and I now realise why they looked strange.
> You've saved the results of your comparisons back in JPEG format, which
> confounds them completely, because they have picked up new artifacts in
> the recompression. What's worse, you've saved them with a high degree
> of compression (possibly similar to that of the original image). I was
> only able to replicate the file sizes by pushing the compression
> quality to a very low level. This makes the files of no use (although
> what you saw on the PSP screen may have been fine).

Yes, owing to a comment in the JPEG FAQ, I always save JPEG at exactly
the same quality and chroma-subsampling as the original.

Now that you mention it, that's a silly thing to do with unblocking.
You also have a good point about rings.  I thought that was a result of
JPEG artifacting, but in the Fuji digicam (ski) image, it could be the
result of excess sharpening.  The nude (twins) image is one of the worst
JPEG encodings I have ever seen which is why I saved it.

Do you want me to post the PSP-de-artifacted images you requested in BMP?

In comp.compression John Costella <jpcostella@hotmail.com> wrote:
> Thanks for those, Bill. The two images you've tested seem to suffer
> much worse from ringing artifacts than blocking, and so it's difficult
> to come to any conclusions. Definitely, for the twins image, the
> maximum PSP setting is doing a good job at removing a lot of the
> ringing -- but that's not what UnBlock addresses.

Good point.  These were just two images that I most wanted to recover.
The first is a real-world image, not some test JPEG file written with
high compression to prove a point.  It's from an old Fuji digicam.

> I'll be addressing the ringing problem separately, so I'll defer a more
> complete discussion of it to then.

Unsharp Mask used indiscriminately is evil.

> Would you be able to process the following test images using PSP?
> http://www.assassinationscience.com/johncostella/unblock/before0*.jpg

Here they are.  What do you think?  Not knowing the names of your
after-unblock equivalents, it's hard for me to form an opinion.

http://cacreeks.com/unblock/before000.bmp
http://cacreeks.com/unblock/before002.bmp
http://cacreeks.com/unblock/before000.bmp
http://cacreeks.com/unblock/before000.bmp

John Costella wrote:
> The methods you implemented were indeed computationally costly
[snip]

True, but also note that my implementations could probably be tuned for
efficiency (both in the algorithms themselves and by rewriting in a
compiled language such as C rather than MATLAB). Since I was concerned
solely with off-line processing in that project, I wasn't overly
concerned with efficiency.

Cheers! --M

Hi Bill,

The second link is no good, and the third and fourth are identical to
the first one.

The 000 one is intriguing -- there are strange sharp-boundaried
blotches of colour. However, this is probably the extreme case.

Thanks again
John

No worries Matt. As I said, I'm looking at very fast implementations,
so that explains why we were a bit at cross purposes.

Thanks again
John

Yes thanks, as you have done below, except that three of those links
are wrong.
Thanks again
John