Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(exr): don't suppress "oiio:ColorSpace" attribute on output #3969

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

lgritz
Copy link
Collaborator

@lgritz lgritz commented Aug 30, 2023

It looks like for some time setting the "oiio:ColorSpace" attribute when outputting an openexr file just got dropped on the floor. I don't think this was the original intended thing to do.

I'm adding it mainly as a short-term band-aid. I think in the long term, it is better to have a cross-project/industry consensus on how to express color space in an exr file, and to coordinate OpenEXR + OpenImageIO + OpenColorIO + DCCs about any necessary conventions. I will open a separate discussion about that.

But in the mean time, maybe this fix helps avoid the problem of having total amnesia about the color space information when we do a "OIIO write exr -> file -> OIIO read exr" round trip.

Hmmm, ops, looks like for some time setting the "oiio:ColorSpace"
attribute when outputting an openexr file just got dropped on the
floor. I don't think this is the right or intended thing to do.

Signed-off-by: Larry Gritz <[email protected]>
@lgritz
Copy link
Collaborator Author

lgritz commented Aug 30, 2023

I should point out a potentially critical issue here: This introduces the possibility that an OIIO-based app can write the "oiio:ColorSpace" attribute, then a non-OIIO-based app can read it, apply a color space transformation, then write the result and simply pass along all the metadata, including this one, unaware that it now inaccurately declares the color space of the image. Which is not only misleading, but potentially could influence the behavior of other OIIO-based apps that subsequently read the new image. Is this better or worse than the files simply not having any information about their color space?

Many studios and apps, by convention, assume that if the filename, like foo.acescg.1001.exr, contains a color space name, that accurate reflects its contents. What happens if the oiio:ColorSpace attribute contradicts the naming of the file? Which hint should "win"?

I think this is why this simple change has languished in my private tree for 9 months without my quite turning it into a PR. I'm very nervous about meaning well here but creating more new problems for people than I'm solving.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant