Repository navigation
Notation for display/view transforms #2
Description
Activity
One reason to prefer
+over/is that it's common practice to embed the color space in filenames themselves, likeshot_element_acescg.1001.exr. So having filename-unfriendly characters like/in color space names actually would be a big inconvenience.Hey Larry,
Technically speaking, we should not be storing non-linear image data in OpenEXR files, i.e., the stored image data should be, to the extent of possible, scene-referred thus there should not be any Display Rendering Transform (DRT) pixels baked in there.
Or are you intending to convey the DRT that was used to view the image?
Cheers,
Thomas
Are color interop forum's goals limited to OpenEXR files?
Are color interop forum's goals limited to OpenEXR files?
You did not give too much context of usage besides writing OpenEXR, so I was not entirely sure where you wanted to go :)
If we were to store output-referred data, e.g., tiff or PNG file, would not the colourspace name be that of the DRT itself? Given the OCIO
sRGB - Display - ACES 1.0 - SDR Cinemaor (Output - sRGBin previous configs) DRT, we know that this issRGBright?Note that we now have a natural split in OCIO 2 between "encoding on the wire" and the part of the DRT that does the tone and gamut mapping, etc..., i.e.,
sRGB - Displayhere, and there is a transform to go toCIE XYZ D65from it.If we are standardising names, let's go full steam across the entire colour imaging system chain or we will only be delaying the problems for future us.
Cheers,
Thomas
Reacted by Larry GritzI've created a proposal along these lines in this OCIO issue.
I think one goal of this group is to move to a world where (say) OpenEXR files have a particular standard metadata attribute name (maybe "ColorSpace"?) that is used to hold the color space name, for which you will have canonical names for the common ones.
But there is an additional wrinkle missing here, which is that some files contain pixels that have also passed through a display/view transform. Ideally, we want to have a single notation that can also encompass this, and canonical names for any common display/view transforms.
something like that, maybe?