Original images may be YUV420 subsampled

[jyrkialakuijala]

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]

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]

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]

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]

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).