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

Allow scene reference transforms in display colour spaces #1617

Open
bram0101 opened this issue Mar 16, 2022 · 0 comments
Open

Allow scene reference transforms in display colour spaces #1617

bram0101 opened this issue Mar 16, 2022 · 0 comments
Labels
Needs Discussion Needs discussion before implmentation, which could result in changes, or a decision not to proceed.

Comments

@bram0101
Copy link

Display colour spaces are combined with view transforms to create output transforms for viewing an image on a display, but they can also be used as input colour spaces and in normal conversions as both the source and destination, which is great as long as you want the same behaviour in all three of these cases. In practice, this isn't always true.

An example would be gamut mapping. When using a display colour space as part of an output transform, I want to use gamut mapping in the display colour space. But, when I use it as an input colour space or I do a normal colour space conversion (either as source or destination), then I don't want to use gamut mapping.

Now, the display colour space does have the to and from transforms, so I could do the gamut mapping in the from_reference transform and no gamut mapping in the to_reference transform. However, when I use the colour space as a display colour space, then I do want to apply the inverse gamut mapping when going to the reference space, and when I use it as a normal colour space, I still don't want gamut mapping when going from the reference space. That won't work.

Another option could be to apply the gamut mapping in the view transform, but I have two problems with that. Gamut mapping is something that should be a part of the display transforms, not the rendering. It's about mapping from one gamut to another, which is what a display transform does, not a view or rendering transform. The second problem is that gamut mapping needs to know the gamut to map to. OpenColorIO is created so that view transforms are display independent. This allows you to have one view transform work on any display, since you just have to swap the display transform. But, if you have to put the gamut mapping in the view transform, then that view transform would be locked to only one display colour space and so the modularity in OpenColorIO stops working. You could create a different view transform for each display colour space, but that would be tedious, create unnecessary duplication, and would still go against the modular design.

So, my proposal is simple, since the display colour spaces can be used as normal colour spaces already, why not allow display colour spaces to also specify scene reference transforms? If the display colour space is used as a display colour space, then the display transforms are used. If the display colour space is used as a normal colour space, then the scene reference transforms are used. If no scene reference transforms are defined, then the current behaviour is used, where the display transforms are used together with the default view transform.

@carolalynn carolalynn added the Needs Discussion Needs discussion before implmentation, which could result in changes, or a decision not to proceed. label Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Discussion Needs discussion before implmentation, which could result in changes, or a decision not to proceed.
Projects
None yet
Development

No branches or pull requests

2 participants