fix: gamma precision

[adskWangl]

Description

This is a PR proposaling to keep the gamma precision.

In some cases, we need more precise gamma values, while the existing rounding operation loses most of the precision. This change will continue to use rounded values to calculate and store color space information, but retain the original value in the "Gamma" parameter. In addition, it can also tidy up existing code.

Tests

I've verified with png/exif.png & python-colorconfig tests. No regression is introduced.

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have updated the documentation if my PR adds features or changes
  behavior.
• I am sure that this PR's changes are tested somewhere in the
  testsuite.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there. (Exceptions: If most tests pass and you can't figure out why
  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
  any failures seem entirely unrelated to your change; sometimes things break
  on the GitHub runners.)
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.
• If I added or modified a public C++ API call, I have also amended the
  corresponding Python bindings. If altering ImageBufAlgo functions, I also
  exposed the new functionality as oiiotool options.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: adskWangl / name: Lumina Wang (0ac6226)

[lgritz]

I think this is ok, but am curious about the circumstances in which rounding to 2 digits was insufficient. What gamma values are you getting in practice that show a precision problem?

I have to admit, I've seen gamma values of 1.8, 2.2, 2.4, and so on. I don't recall coming across files with anything other than those round numbers. Are you seeing truly arbitrary numbers? How is that useful for anyone, if they are not using the handful of fairly standard values?

[adskWangl]

@lgritz Thank you for your reply!
Yes, I notice this issue because we have some files with different gamma values. (e.g. A PNG with encoded gamma 1.5 returns oiio:Gamma 0.67. And when we perform 1/gamma in some shading code, it becomes 1.4925... This results in some subtle visual differences compared to using the original gamma values ​​from the PNG file.)

[lgritz]

OK, makes sense.

Did you consider trying it in a way that still does the rounding, but simply preserve more significant figures?

I think the situation I was trying to guard against is having a value like 2.19998, and if we print that (say, when displaying the metadata), many users are going to be confused or think it's silly behavior. EVERYBODY KNOWS THIS SHOULD BE GAMMA 2.2, and it seems like it would be kind to users to essentially make it "snap" to that value. That's what I was thinking at the time, anyway. With all the common values of 2.2, 2.4, etc., I thought 2 digits was enough, but you have pointed out situations where perhaps it is not.

On the other hand, your change doesn't seem to alter the output of anything in the testsuite, so maybe that was a unique case I looked at years ago and in general it will be just fine without the rounding?

I'm inclined to accept this as-is, but maybe if people complain, we can revisit and possibly go back to a rounding solution, but perhaps with more than 2 significant digits.

[adskWangl]

Yeah. I think rounding common values like 1.8 / 2.2 / 2.4 is reasonable, as well as shortening the verbose (g{}_rec709_scene). I'd like to keep this behavior and this is also why no change happens to the output of testsuite.

In my case, I did find out rounding to 4 digits should be alright. However, if someone wants to limit the error to the range of epsilon, such as 1e-6f, then they might argue for retaining more. Given that current OIIO typically keeps the external input gamma value constant in oiio:Gamma, I then prefer to do so. I agree we can revisit it if people complain.

[lgritz]

LGTM

[zachlewis]

EVERYBODY KNOWS THIS SHOULD BE GAMMA 2.2

Believe it or not, the canonical CIF g22_adobergb_display and g22_adobergb_scene color spaces specify an exponent of exactly 563 / 256 (=2.19921875)...! So, our color space identification heuristics need, at minimum, to be able to differentiate between 2.199 and 2.2, because, absent any other information, the former would strongly imply Adobe RGB (1998) primaries, not rec709...

FWIW, the PNG gAMA chunk "is a four-byte unsigned integer[...] representing the gamma value times 100000" -- maybe that's our rounding sweet spot? Or maybe we could cut out the middleman entirely, and just internally use the same integer representation for oiio:Gamma as PNG does for gAMA...?

In truth, I do believe set_colorspace_rec709_gamma may not long for this world, so I'm hesitant to make too many more suggestions -- but I will say, I'm really not a fan of the bit where we use that "g{}rec709_scene" string template to return arbitrary / non-"canonical" / CIF_ish values. In general, with the PR I'm about to birth imminently, I'm trying to encourage OIIO devs to constrain their use of hardcoded color space names / aliases throughout the codebase to a single convention -- i.e., a set of colorInteropID-style strings that match the names of color spaces in an internal "interop-identities" config, which serves as the basis for all the color spaces OIIO "knows about" and can recognize in other OCIO configs.

[zachlewis]

...but I suppose I'm cool with this for now :)

Thanks Lumina!

[lgritz]

set_colorspace_rec709_gamma may not long for this world,

Absolutely. I'm expecting a lot of this to get overhauled fairly soon, and for most of our color management to rely on the standard CIF tokens, and even the "gamma" metadata will have a lot less importance, most of the time.

Believe it or not, the canonical CIF g22_adobergb_display and g22_adobergb_scene color spaces specify an exponent of exactly 563 / 256 (=2.19921875)...!

Of course it is. Honestly, I wouldn't be surprised to hear that for color science purposes, by definition, π = 3.15.