wyohknott / image-formats-comparison Goto Github PK

Google has a new image codec called pik that they're working on. According to https://encode.ru/threads/2814-Psychovisual-analysis-on-modern-lossy-image-codecs the results are quite good. It would be great to have it included here.

I'm not sure what release fixed this, but Firefox is now color correcting all images written to a canvas. Previously there was a problem with this tool where images decoded in Javascript and then written to canvas would not be color corrected, see #11 but now the issue is the opposite. Because of the way the comparison script works internally, the image data is actually copied between two canvasses, which means that Firefox imposes color management twice!

See the following comparison: the image in this comparison tool on the left is strongly desaturated (on my color managed WCG monitor) compared to the same image shown in a color managed viewer (eye of Gnome).

There is no issue (as far as I know) on Chrome, because Chrome appears to be treating canvases as always sRGB, only doing color correction at the final rendering stage. Chrome is therefore not capable of rendering WCG images on a canvas, while Firefox is.

Note that I fixed this issue on my fork some time ago when I rewrote the script to only use one canvas, along with a lot of other bugs.

I have a profiled display and color management enabled in Firefox. Because of the way some images (BPG, JXR, KDU, OpenJpeg) are displayed - presumably decoded in Javascript on my browser - they manage to bypass the color management system and they display heavily oversaturated. This makes it difficult to compare these images with the ones that are supported natively, since they have the wrong colors.

Possible solutions:

• some way to force Firefox to treat these Javascript loaded images like any other, so that it will color manage them?
• some way to detect whether the user has color management enabled, and load prerendered PNGs instead? or an option to do that?

Hi, this is related to #4 but not the same issue.

The issue is that some formats like BPG (the ones rendered by Javascript?) are getting resampled with Lanczos2 before they're rendered into a PNG for the browser, and other formats are not getting resampled at all (or at least are resampled very badly) - including the original image! This leads to some absurd results where parts of an image look better on BPG small than they do in the original, and makes other comparisons difficult.

A good example of this is Seikima-II, which shows a large number of red and blue subsampling artifacts in the original. The visual quality of the arm in the picture is actually better in BPG small due to getting resampled: https://wyohknott.github.io/image-formats-comparison/#seikima-ii&bpg=s&png=l

The solution to this is pretty simple; either don't resample any of the images before displaying them, or resample all of them the same way.

Tested in Firefox 71.0 and Chromium 78.

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.

Sorry for filing an issue, but I'm not sure how else to contact you.
I was looking at the information here:
https://wyohknott.github.io/image-formats-comparison/report.html
And see that Daala, AV1, JPEG XR and JPEG 2000 all appear to beat FLIF for compression on lossless images. This surprised me a bit because FLIF had been rated best for lossless compression in the ICIP 2016 Grand challenge.
http://people.xiph.org/~unlord/ICIP2016/icip2016grandchallenge.pdf (page 35)
That comparison included JPEG XR and JPEG 2000.

I believe I had also seen claims (with numbers) about FLIF beating other codecs for lossless image compression.
I have no horse in this game or vested interest, I was just wondering if you have any idea why there is such a difference in the results?

Hello,

I would like to use your photos from this project for my research work. Could you please let me know if I can do it and what is the best way to cite your work in our publication?

Best regards,
Renata

The slowness is caused by having a large data URI in an inline style for the image containers.

I tried changing the setSize function to put the background image in a style element instead, by replacing the line that sets el.style.backgroundImage with the code below:

var styleEl = getElId(side + "SideStyle");
if (styleEl == null) {
    styleEl = document.createElement("style");
    styleEl.id = side + "SideStyle";
    styleEl.textContent = "#" + el.id + "{}";
    document.head.appendChild(styleEl);
}
styleEl.sheet.cssRules[0].style.backgroundImage = 'url(\"' + src + '\")';

This fixed it in Firefox, and also made it slightly smoother in Chrome as well.

https://github.com/cloudinary/fuif

This would be nice to have.

Update with new version of AV1 (Upstream)