OpenImageIO icon indicating copy to clipboard operation
OpenImageIO copied to clipboard

feat: Support display color space interop IDs in I/O

Open brechtvl opened this issue 4 weeks ago • 1 comments

Description

  • Display referred interop IDs are now chosen over scene referred ones by default on file read. This more closely matches the standards for CICP, ICC and other color metadata. Most images will now have oiio:ColorSpace set to srgb_rec709_display rather than srgb_rec709_scene on file read.

    There is groundwork to add control to prefer either display or scene referred, but it's not exposed yet. Probably it should be in the config spec so it can be controlled per image, and this requires more refactoring.

  • Both srgb_rec709_scene and srgb_rec709_display are now (distinct) built-in color spaces. The built-in sRGB color space name was changed to be an alias of srgb_rec709_display rather than srgb_rec709_scene.

  • Previously only srgb_rec709_scene was recognized as sRGB for file metadata and display, now srgb_rec709_display and g22_rec709_display are treated as sRGB as well.

    The reason for g22_rec709_display behavior is that this type of display is often used to correct for the discrepancy where images are encoded as sRGB but usually decoded as gamma 2.2 by the physical display. By encoding it as gamma 2.2 and claiming it's sRGB the transfer functions cancel out exactly.

  • g24_rec709_display is now recognized as having gamma 2.4, and the name g24_rec709_scene was replaced with ocio:g24_rec709_scene since the former is not an official interop ID.

  • cio:itu709_rec709_scene and ocio:lin_ciexyzd65_display were added to complete the list of interop IDs in OCIO configs that match a CICP.

Tests

Added basic test for g22_rec709_display behavior.

Checklist:

  • [x] I have read the contribution guidelines.
  • [x] I have updated the documentation, if applicable. (Check if there is no need to update the documentation, for example if this is a bug fix that doesn't change the API.)
  • [ ] I have ensured that the change is tested somewhere in the testsuite (adding new test cases if necessary).
  • [x] If I added or modified a C++ API call, I have also amended the corresponding Python bindings (and if altering ImageBufAlgo functions, also exposed the new functionality as oiiotool options).
  • [x] My code follows the prevailing code style of this project. If I haven't already run clang-format before submitting, I definitely will look at the CI test that runs clang-format and fix anything that it highlights as being nonconforming.

brechtvl avatar Dec 01 '25 19:12 brechtvl

Draft because:

  • ~~This depends on and includes the changes from #4964.~~

brechtvl avatar Dec 01 '25 19:12 brechtvl

Regarding the current status for this PR. I'm not currently planning further changes. There's more refactoring that could done, for deferred color space determination and more unified code. But that's probably best left for another PR?

I think the main decisions to be taken are:

  • [x] Defaut to scene or display referred? (Consensus seems to be display.)
  • [x] Should sRGB be srgb_rec709_scene (backwards compatibility) or srgb_rec709_display (consistency with default image load) or even be controlled by color:prefer_image_state? (Consensus is srgb_rec709_scene)
  • [ ] Write CICP and ICC even for scene referred color spaces? (In my opinion, yes)
  • [ ] Is the special g22_rec709_display handling a good thing? Or too confusing or undesirable for users with a Gamma 2.2 workflow? Or we won't have a good answer soon, so remove the exception and defer the decision? (Unsure)

brechtvl avatar Dec 15 '25 19:12 brechtvl