>From: Elle Stone
>Date:02/22/2015 3:59 AM (GMT-10:00)
>Does anyone use ACES in conjunction with ICC profile color management?
>If so, do they use OpenEXR to store RGB data?
Yes. A common user here :)
I think you would do well for GIMP by keeping ICC compatibility for color management and adding later an ACES (OCIO) implementation for color transformations. If you ask me, from a common CG/VFX user' point of view, both solutions help each other very well.
By convention, OpenEXR has been made for storing 'scene-linear' images. But something many users don't realize is that EXR format is a module of a more complex system. A system the common user has not really full access to - at this moment, OCIO implementations don't solve all requirements for a complete VFX workflow. Surely new version 1.0 will help to close this gap, but at this moment, it's very difficult for a common user to have an ACES workflow working properly by itself (even in the most basic operations) without ICC color management help.
i.e. Let's say we shoot in RAW for a photo-based texture. Profilers are able to deliver DCP or ICC profiles from our specific camera. So we have a profile and raw-develop a proper scene-referred image. Now, how do we convert this image to ACES colorspace with the tools common user has by hand? Don't know any OCIO implementation able to do this 'IDCT' and then the 'IDT' for custom cameras - would be great if this tool could be available for the common user. However we can easily perform this conversions in floating point domain with ICC profiles (within AfterEfects or ColorTranslator) and continue with our workflow.
There are many other ways both solutions can help each other.
In the specific case of GIMP and OpenEXR files, it's not only a matter of being able to work with ICC scene-referred profiles, but it would need also a very robust output/display simulation module (graphic packages call this, color proofing) to be able to work with ICC profiles in the 3 states proposed by the original framework.
Please, keep in mind that within the framework, output-referred, color-rendering and 'look' transformations are applied on the fly - externally to the stored data - by other modules in the system when outputting or displaying exr images, and resulting color appearance are only 'baked' in exr files for debugging inconsistencies (as negative numbers issues and such).
In this context, an idea for GIMP implementation with ICC profiles could be:
1. Scene-referred (SR) images can be assumed linear automatically. So when the user pick an output-referred (OR) working space as they always do, a matrix profile (linear TRC) of this profile can be applied momentarily to the image instead. The simulation output could use the OR version of this profile to proof colors to monitor. If no monitor is selected, an sRGB profile (with 2.2 gamma instead of sRGB gamma) could be used as generic profile. Additionally, you could provide presets for aRGB-range monitors (2.2) and DCI-P3 monitors (2.6) or allow for any display profile to be selected. The simulation process needs then a concatenation from working space to output to display. Colorimetric rendering intents are recommended for this process, but the option for switching to other rendering intents should be available as well, because differently to CTL, with ICC specs we are able to have access to the color rendering (or color re-rendering) within the profile in the Perceptual Rendering intent (for well-constructed SR ICC profiles). So in this context, the user will be working in SR linear state but previewing according to the desired output medium (ODT equivalent of the framework) and even with a pleasant color rendering (the RRT equivalent of the framework) by 'achieving exactly the desired look' and 'requiring only minor tweaking of the pixel values'. If Adjustment Layers are available, real non-destructive editing is possible. This is pretty much the way AfterEffects and Photoshop works. But in Photoshop the color-rendering from Perceptual intent in SR profiles work only in 8-bpc and 16-bpc. It doesn't work in 32-bpc. In AfterEffects we can use the ColorProfile effect in an Adjustment Layer instead.
2. Output-referred (OR) images in the framework contains color rendering only, but no compensation for output standard or output device. So, if GIMP is able to work properly with SR images in floating point domain (which is allowed by ICC specs) as described previously, then saving data for OR state is easy. The linear image can be simulated to output device/medium with Relative Colorimetric intent, then if 'natural' color adjustments are performed by the user, it may be considered 'color-rendering' for that specific output medium. When saving, no gamma-correction would be applied, but of course, some tone-curve and saturation adjustments will be introduced by the user - so this would still be an image in OR state according to the framework.
3. Indirect output-referred (IOR) images are probably the most difficult to save to exr files in accordance with the framework. Because 2 inverse compensations should be applied before saving to exr: one for a special color-rendering transformation (RRT) and the other for the output transformation (ODT). If GIMP is able to work with OR images as described previously, getting rid of the ODT before saving is easy. And if GIMP is able to work with images in SR state as described previously, getting rid of the RRT could be somehow possible if there's an inverse color table for the Perceptual intent in the SR ICC profile. Even when both rendering intents are not exactly the same - doesn't compensate for glare - it's somehow similar (ICC version was first, just in case). However this table is commonly not included, but new ACES specs already addresses for RRT and inverse-RRT (which is great!) and have the idea this won't be an issue in short-term. But right now, the tricky part is the LookModificationTransformation (LMT). If non-destructive editing is available in GIMP, this aspect could be fulfilled as well. Though this image state will be the less used - if even used - by the vast majority of GIMP users, I think.
>I wish OpenEXR supported ICC profile color management by means of
>embedded ICC profiles.
Useful thing about OpenEXR is that it allows for arbitrary metadata. You might be interested in supporting solutions like ProEXR: http://www.fnordware.com/ProEXR/
>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
Please, take a look to the OpenEXR_iccProfileAttribute.cpp of the ProEXR sourcecode for AfterEffects:
https://github.com/fnordware/openexrAE
It copies the profile in the uncompressed EXR file. According to Brendan Bolles (ProEXR developer) the FrameSeq_Color.cpp can also extract chromaticities from the ICC profile to store in the standard EXR attributes and vice versa. VERY usefu!
Greetings,
Gerardo