Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

[Elle Stone]

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