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.