Log in

View Full Version : H.264 for Image coding


Pages : 1 [2]

Dark Shikari
12th October 2010, 07:53
I do agree psy optimizations should be use wisely. The psy optimizations can easily trick our mind in moving pictures but not still picture.I find it's generally the reverse: you can get away with far more in still images because you don't have to worry about temporal stability.

lithoc
12th October 2010, 08:28
I find it's generally the reverse: you can get away with far more in still images because you don't have to worry about temporal stability.

May be I'm wrong, theoretically our mind have a very short memory and cannot retain so much information when viewing a motion pictures. So, if there's compression artifact it can easily get away with it.

But in a still picture, it's easier to detect compression artifacts.

Perhaps that's what Psy optimization job to handle it

Dark Shikari
12th October 2010, 08:31
May be I'm wrong, theoretically our mind have a very short memory and cannot retain so much information when viewing a motion pictures. So, if there's compression artifact it can easily get away with it.The eye is designed to capture motion. You can see motion incredibly well even at the edges of your perception, even if you're not focused on it. You can only see detail where you're currently looking.

Thus, in a video, if a temporal artifact occurs anywhere on the screen, your eyes are drawn to it. By comparison, you can only see a spatial artifact (e.g. in a still image) if you actually look at it.

That's my hypothesis, at least.

lithoc
12th October 2010, 09:07
in a video, if a temporal artifact occurs anywhere on the screen, your eyes are drawn to it.

Very true.

Thanks for your explanation.

jmartinr
12th October 2010, 09:22
May be I'm wrong, theoretically our mind have a very short memory and cannot retain so much information when viewing a motion pictures.

The Human Visual System can retain a lot of information for a very short period. See http://en.wikipedia.org/wiki/Iconic_memory

kidjan
13th October 2010, 01:54
You can easily apply a deblocking postfilter to JPEG if the only problem is blocking. This is far easier than switching image formats.

Well, for starters, I don't think that's the issue with JPEG. I think JPEG struggles with gradients and low-detail portions of the image. I tested this hypothesis, here are my results (http://goldfishforthought.blogspot.com/2010/10/comparison-webp-jpeg-and-jpeg-xr.html).

I did reproduce your results with parkrun, more or less--JPEG simply does a better job with that image except at really low bitrates where everything looks horrible anyway. But on several other images I've tested with, it's pretty clear to me that WebP generally looks better, and especially at low bitrates.

I also tested JPEG XR, and unless I screwed up the encoder configuration (which, btw, is possible due to the mangy API MSFT provided), it is substantially worse than either JPEG or WebP. Maybe it's just their encoder implementation, but you have to wonder why they'd even bother releasing it if .NET's JPEG compressor was going to eat it for breakfast.

lithoc
13th October 2010, 04:03
Well, for starters, I don't think that's the issue with JPEG. I think JPEG struggles with gradients and low-detail portions of the image. I tested this hypothesis, here are my results (http://goldfishforthought.blogspot.com/2010/10/comparison-webp-jpeg-and-jpeg-xr.html).



IMHO, WebP is 4:20 and JPEG is 4:2:2. Does it have any impact on SSIM results?
WebP can be seen as higher compression but in actual fact red & blue have less resolution.

Can the raw pictures SSIM normalize 4:20 vs 4:2:2 in loseless mode?

For casual viewing, any 4:2:0 source is perfectly fine for me, that what lossy compression job is to take out whatever human eyes can't see anyway :)

roozhou
13th October 2010, 08:07
IMHO, WebP is 4:20 and JPEG is 4:2:2.
JPEG supports both 4:2:2 and 4:2:0.
AFAIK most JPEGs from DC are 4:2:2 and most JPEGs on webpages are 4:2:0.

kidjan
13th October 2010, 18:09
IMHO, WebP is 4:20 and JPEG is 4:2:2. Does it have any impact on SSIM results?

First, no, because SSIM only operates on the luma channel.

Second, the colorspace depends on the encoder. JPEG standard allows 4:4:4, 4:2:2 and 4:2:0 (http://en.wikipedia.org/wiki/JPEG#Downsampling). The last one is by far the most common, in my experience. Most video encoders typically use the last one as well.