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

[Joseph Goldstone]

There’s this paragraph on page 1:

At this time the committee's work is not complete, and several aspects of what is described below are not fully resolved. This document does not attempt to define a standard. The goal of this document is to encourage interested parties to experiment with CTL and its use in actual production workflows, and to provide feedback to the author. However, the text below should not be regarded as a draft of what the Image Interchange Framework committee may recommend in the future. The committee's final recommendations may differ significantly from what is described here. 

The ACES committee (an unfortunate change of name from the Image Interchange Framework committee) agreed with Florian on much of what was published in this document, but let go of indirect output referred imagery or output referred imagery in OpenEXR, IDCES and ODCES as explicitly named things, and a lot of other stuff. For example, the ACES 1.0 release carries a lot of the metadata as clip-level XML that the paper you reference proposes be carried as OpenEXR attributes. 

The ACES 1.0 source and doc bundle can be reached from this page:

http://www.oscars.org/science-technology/sci-tech-projects/aces

And if you are going to be looking at how to make OpenEXR files for an ACES workflow, look at SMPTE ST 2065-4:2013, “ACES Image Container File Layout�.

The Academy doc set is in the unfortunate position of trying to provide color-managed substrate around which digital motion picture workflows could be built, while trying to stay agnostic with regards to workflow and not provide a ‘best practice’ there. I’m not any sort of official spokesperson for the Academy (just an 11-years-on-the-committee worker bee) but I think they will stay agnostic, and see what kinds of workflows are developed by productions and by interested individuals. My guess is that over the next year the ACES discussion group at

https://groups.google.com/forum/?hl=en#!forum/academyaces

will move a bit from developer conversations to user conversations. And I hope that, supplanting that discussion group which is pretty linear and textual, we’ll see ACES usage discussions on websites like your own (which I wish had been there in the early 2000s when I was trying to use littlecms for movie production).

—joseph

On Feb 21, 2015, at 5:00 AM, Elle Stone <address@hidden> wrote:

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
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel

---

This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com

---