openimageio-tools: handling of gamma for JPEG files in "iv" is weird

[mfvescovi]

A Debian user filed the following bug report:

http://bugs.debian.org/668476

It's not related to packaging, so fowarding it here. Thanks for your efforts in fixing this.

Cheers.

[2bits]

@mfv-deb I brought this issue up a while back in #251. Not being an expert, I accepted the explanation that this is a feature, not a bug. Now I see this is tagged with a bug label. Maybe something has changed.

[lgritz]

Closing because I believe this is fixed -- I'm pretty sure that the jpeg reader assumed that all JPEG files are sRGB (which they are, according to spec).

[snogglethorpe]

Do you know when this was fixed? iv in version 1.1.3 (via debian) still shows the problem.

[I reported the bug on Debian]

[lgritz]

I'm reopening, and for clarification, I'm reposting the Debian bug here:

Package: openimageio-tools Version: 1.0.0+dfsg0-1 Severity: normal

[Sorry if this is a bit long; issues involving image gamma are always kind of confusing, so I'm trying to be as explicit and verbose as possible...]

Given:

1. A typical PNG image file, "foo.png", which was encoded using a standard encoding gamma correction value of 1/2.2 (0.4545), and has an explicit PNG gAMA chunk recording that value.
2. A JPEG file, "foo.jpg", produced from "foo.png" file using the imagemagick command "convert foo.png foo.jpg".
3. Another PNG file, "foo2.png", produced from "foo.jpg" using the imagemagick command "convert foo.jpg foo2.png"; note that foo2.png doesn't have an explicit gAMA chunk.

Then:

• Most image display programs (imagemagick, eog, geeqie, qiv, ...) display all of the files identically. In other words, they assume that the encoding gamma correction value is 1/2.2 (0.4545) for both JPEG files, and PNG files without an explicit gAMA chunk.
• "iv foo.png" and "iv foo2.png" displays the image "correctly" (matching what other image-display programs do), suggesting that it assumes a default encoding gamma correction value of 1/2.2 for PNG files.
• However, "iv iv.jpg" displays the image much too dark, unlike all other programs. By using the ")" key-command to change the "gamma" value to 2.2, the image then looks correct.

=> Thus the bug: it appears that iv assumes an encoding gamma correction of 1.0 for JPEG files, which does not match standard practice.

[As an aside, the term "gamma" value displayed in the iv GUI is a bit confusing; it appears to actually be "encoding gamma correction divided by display gamma correction."]

Thanks,

-Miles

[lgritz]

I don't suppose you could send me foo.png? I want to make sure we're reading the headers properly and deducing gamma correctly, and walk through these steps exactly on my end.

[snogglethorpe]

Sure. Look at this gist: https://gist.github.com/4679014

[A gist 'cause you can't attach an EXR file to an issue... even getting it into the gist was a big pain. TT ]

It includes the same image file, in EXR, PNG, and JPEG formats.

The EXR file is the "master", and of course is encoded in linear-light, so shouldn't have gamma issues (haha!). The other files have a gamma-correction of 1 / 2.2. In the PNG, there's an explicit gAMA chunk describing this; in the JPEG file it's implicit (because of sRGB).

The PNG and jpeg files display identically with every program I've tried -- "eog" (gnome), "display" (imagemagick), web browsers (firefox, chrome), "geeqie" (not so common, but a nice and generally capable image display program). Most of these can't handle EXR, but "display" does, and it displays darker than the 8-bit files, similar to the way iv does.

"iv" displays the PNG file identically to the other programs, but displays the EXR and JPEG files much darker, suggesting that indeed maybe the issue is that iv is doing the wrong thing on display: using the correct gamma adjustment when reading JPEG files, getting linear-light values internally... and then using the wrong gamma-correction when sending to the display. Of course then that suggests PNG input is being handled incorrectly...

[I do not know the extent to which those other programs even try to handle gamma; I'm guessing that traditional "stupid" image display programs tended to get thing right accidentally by simply never doing any gamma adjustment at all, and benefiting from the fact that the display protocol uses a similar gamma correction to 8-bit file formats...]

[mfvescovi]

Any news about this issue?

[mfvescovi]

Oops... ;-)

[wavexx]

I can confirm this issue is still present in debian's 1.7.8. All JPEG files I'm looking at are too dark, I need to manually ramp the gamma. It's a shame, as iv is otherwise one of the few color-managed image viewers around.

[lgritz]

I think this has long since been fixed. Closing.

[kfjahnke]

Is it possible that this is still an issue? I found OpenImageIO because I am looking for an alternative method to open image files. Until now, my image and panorama viewer lux is using libvigraimpex, which is not getting much support anymore, and I need an image i/o library which can handle transfer of image data to/from strided memory - currently I handle image data via vigra::MultiArrayViews which are very close to NumPy ndarrays. So OpenImageIO looks like an ideal candidate - I can pull out the strides from the vigra object, convert it to bytes (vigra uses strides in terms of the contained data type) and pass it to oiio. Before I touch any code I browse what there is in terms of documentation, echo, comments - and I try the tools. And, lo and behold, iv displayed all my test images with the wrong gamma. I could fix that by setting the GAMMA environment variable (took a while to figure that out), but I feel that this should be set to a sensible default automatically - it's a display issue, not a matter of what's inside the image file. I may be wrong, but I don't think that there are any displays with a linear gamma, which is seemingly what iv uses if there is no GAMMA environment variable. Seeing all my test images displayed with obviously wrong gamma almost made me abort the investigation into OpenImageIO because it was such a glaring mistake - luckily I did a bit of browsing and so I still have hopes that it will work for me. How about setting a 2.2 gamma as the default if there is no GAMMA environment variable?

[wavexx]

The behavior of iv 2.4 still matches what I wrote in 2016, so I still consider iv's behavior broken (at least by default). And @kfjahnke ... thanks for mentioning the GAMMA env. Is it mentioned somewhere? Definitely not in the iv man page.

[kfjahnke]

I saw the behaviour on debian12 running v.2.4.7.1. I found the reference to the GAMMA environment variable when browsing the mailing list to see if anyone had yet come up with this issue. This is the post: https://lists.aswf.io/g/oiio-dev/message/1117 There, @lgritz mentions that iv honours the GAMMA environment variable. So to work around the built-in default gamma of 1.0 just set that environment variable to 2.2 and the display should be fine. Obviously, this gamma value is the display gamma. The unfortunate default gamma of 1.0 affects the display of all images, I tried with a bunch of my test images, so it's not about what's inside the image file, but how the internal linear RGB representation is converted to produce a reasonable-looking image on the monitor - at least that's how I understand it.

[lgritz]

I don't think I mind making 2.2 be the default and if you want something else, that's when you use the GAMMA variable.

Would that change give you what you need?

[kfjahnke]

I don't think I mind making 2.2 be the default and if you want something else, that's when you use the GAMMA variable. Would that change give you what you need?

I think that should do the trick. Thank you for taking note and replying so quickly!

[lgritz]

Proposed fix in #4118

[kfjahnke]

In your code, you already hint at a much larger issue looming behind the simple 'which gamma' question:

    // FIXME -- would be nice to have a more nuanced approach to display
    // color space, in particular knowing whether the display is sRGB.
    // Also, some time in the future we may want a real 3D LUT for
    // "film look", etc.

This issue has been bugging me - I have an image viewer going as well. I see more and more devices with colour space beyond sRGB turning up. And I can't really see what to do about it: what would be needed is a portable way to figure out what the actual display is

• being sent
• capable of
• set to

Going down that path is opening a can of worms, and having several vendors out there who each have their own way of doing things does not help. So far I am chickening out: I do the internal processing in linear RGB (so oiio should provide precisely what I need in lux) and convert to sRGBA which I have SFML push to an openGL texture for display, hoping for the best. openGL does at least provide a handle to serve data to a fair share of what's out there. If you come up with a clever scheme for dealing with non-sRGB display units and/or handling different looks, I'd be very interested indeed.