Hi Eli I would look at a project called OpenColorIO (OCIO). It is a common way many DCC applications handle color these days via luts, cdl and a variety of other color transforms. Through OCIO you could transform to scene linear, apply a viewer transform and have the appearance of working in some type of display referred space. It also includes a tool to bake icc files which is how the ACES profile for Photoshop was created.
http://opencolorio.org/ http://opencolorio.org/userguide/baking_luts.html?highlight=icc https://github.com/imageworks/OpenColorIO There are ACES config files for ocio too https://github.com/imageworks/OpenColorIO-Configs On Sun, Feb 22, 2015 at 6:03 AM, Elle Stone <ellest...@ninedegreesbelow.com> wrote: > On 02/21/2015 02:26 PM, Joseph Goldstone wrote: > >> 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”. >> > > On 02/21/2015 07:10 PM, Gonzalo Garramuno wrote: > >> This is handled by the ACESclip metadata and CTL. It allows you to >>> have different Look Mod Transforms and save them along your image. >>> Or a gradeRef to convert from and to a different space (like log) >>> and apply ASC CDL transforms (SOPNode and SatNode). >>> mrViewer supports the first variety and is in progress to support >>> the second variety, too. >>> >> > Thanks! for the links and the clarification on how ACES is used with > OpenEXR files. I've been peeping over my shoulder at the ACES workflow and > how people in the world of cinema handle color management for a while now. > > The context of my question about the OpenEXR document on ACES wasn't about > ACES per se but rather about how to use OpenEXR in a strictly photographic > workflow, as a way to transport high bit depth RGB data between various > photographic image editors that use ICC profile color management (the > ACES-OpenEXR propsal mentions encoding nonlinear RGB data). > > The specific question was whether photographic image editors should allow > writing nonlinearly encoded RGB data to OpenEXR files, or whether instead > the RGB data should be converted to a linear gamma ICC profile before being > exported as OpenEXR. > > In the usual photographic workflow, editing operations are performed > directly on the RGB data to intentionally modify the scene-linear nature of > the raw data that was captured by the camera. From the photographer's point > of view, whether data should be exported as linear or nonlinear RGB depends > on why the photographer wants to export the data. For example, if the goal > is to rescale the image in another image editor, the data should be > converted to a linear gamma ICC profile. But if the goal is adding or > removing noise, usually the photographer will prefer results of operating > on perceptually uniform data. > > The question of writing nonlinearly encoded RGB values as OpenEXR came up > because the GIMP devs are currently working on GIMP's OpenEXR read/write > code. We (I contribute to GIMP development, mostly in the area of ICC > profile color management) want to accomodate the needs of photographers > while making sure we follow OpenEXR specifications and best practices. > > On 02/21/2015 02:26 PM, Joseph Goldstone wrote:> > >> 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 >> <https://groups.google.com/forum/?hl=en#%21forum/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). >> >> > Does anyone use ACES in conjunction with ICC profile color management? If > so, do they use OpenEXR to store RGB data? > > I wish OpenEXR supported ICC profile color management by means of embedded > ICC profiles. > > If the data is converted to a linear gamma ICC profile before export as > OpenEXR, then the chromaticities and white point can be used to construct > an ICC profile. But many applications that do read ICC profiles, don't read > or write OpenEXR chromaticities plus white point and don't have code that > constructs ICC profiles from chromaticities plus white point. > > > Elle > > > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel >
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
