search

WyohKnott / image-formats-comparison

MIT License
19 stars 5 forks source link

Original images may be YUV420 subsampled #4

Open jyrkialakuijala opened 7 years ago

jyrkialakuijala commented 7 years ago

Compare a YUV444 image at:

https://drive.google.com/file/d/0B0w_eoSgaBLXdURZb1hZSDhxRUU/view

With:

Subset1 image at https://raw.githubusercontent.com/WyohKnott/image-formats-comparison/gh-pages/comparisonfiles/subset1/Original/Mural_in_Northeast_Pavillion__Thomas_Jefferson_Building_by_Elmer_E._Garnsey_11670u_edit.png

It seems to me that originals are YUV420 subsampled, and have their upsampling done without fancy upsampling. The use of YUV420 brings quality losses into originals and disadvantages to YUV444 approaches (like guetzli and PIK) over YUV420 approaches when benchmarking with this image set. Further, a better color space that will be in an disadvantage position if the reference image set has already been subsampled into a particular colorspace (because more information is kept in the Y direction). Changing the Y direction to be more psychovisually compatible will work on real originals, but will fail on images where the relevant U and V information has been removed.

WyohKnott commented 6 years ago

originals are YUV420 subsampled

Yes.

have their upsampling done without fancy upsampling

No image has been upsampled. They all are encoded as is. YUV444 is rot supported by every codec, especially video ones, and my image sets were YUV420 anyway.

magicgoose commented 6 years ago

YUV444 is not supported by every codec, especially video ones, and my image sets were YUV420 anyway

Perhaps it would be more fair to use 4:4:4 images as inputs and only convert to 4:2:0 for codecs which can't accept 4:4:4 as input. Your method unnecessarily penalizes codecs which can deal with chroma information more efficiently than simply subsampling it even when this will give visible distortion (even without any further compression). For example, on certain kinds of inputs lossy WEBP loses to JPEG because the former cannot store full resolution chroma, but with your inputs this cannot be seen because they are already 4:2:0. Why not let a codec do everything it sees as optimal, as long as it hits the target file size?

afontenot commented 4 years ago

I agree with this issue. It's basically required for any serious image codec to support 4:4:4 images. BPG is a video-derived codec and supports it, for example (and obviously HEIC does). What would switching to YUV444 input mean getting rid of? Daala? VP9? Surely AV1 supports 4:4:4, since they're now officially trying to do an image codec with it.

It would be nice to at least have an optional "YUV444 mode", even if codecs that don't support it were just disabled entirely in that mode.

afontenot commented 4 years ago

Those of you subscribed to this issue might be interested in my fork: https://afontenot.github.io/image-formats-comparison/ I have fixed this and many other issues. It's still a work in progress (some missing codecs, I haven't done subset2 yet, and ~I haven't fixed the bug where the page ignores your settings in the URL~), but I'm happy to work on improvements over there.

To fix this one, I recreated the test image set from scratch using the original high res sources. All the codecs are operating without subsampling (I removed WebP).