On 02/20/2015 04:03 PM, Christopher Horvath wrote:
I would strenuously argue this is correct for the R, G, & B channels, specifically:Others have maintained that statements in the OpenEXR documentation such as "By convention, OpenEXR stores scene-referred linear values in the RGB floating-point numbers" (Technical Introduction to OpenEXR) should be interpreted to mean that OpenEXR RGB data should always be encoded as linear gamma data, and that reading and writing of non-linearly encoded RGB data shouldn't be supported. Though I'm sure there are wildly differing uses. There's no reason you couldn't create Rnonlinear, Gnonlinear, Bnonlinear channels or something similar, if you intend to break with convention. C
The proposed ACES workflow using OpenEXR (UsingOpenEXRandCTL.pdf) discusses storing output data that's not scene-linear as part of an overall ACES workflow. For example page 11, ImageState, has three values: SCENE_LINEAR, INDIREDT_OUTPUT_REFERRED, and OUTPUT_REFERRED.
When OUTPUT_REFERRED RGB data is stored, is it stored in something like Rnonlinear, Gnonlinear, Bnonlinear? Or does it just use bog-standard RGB, relying on the special metadata field to indicate the state of the data?
In interest of full disclosure, I'm the only GIMP dev that's lobbying for letting the user decide how to encode data stored as OpenEXR, as dictated by the user's own purposes. I do agree that the concern to not violate "officially sanctioned" ways of using OpenEXR is an important concern.
I think the devs would be much happier about allowing nonlinearly encoded RGB data if there were an officially sanctioned metadata field that would indicate "nonlinear" or better yet hold an ICC profile. But having kept tabs over the years on discussions about OpenEXR that start with "can we have ICC profile support", I don't think that's very likely to happen any time soon.
Elle _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
