I think you just coined a new phrase!
It’s called replying from your phone.
There are some misconceptions here. I worked extensively in DTP and ICC creation before my time in motion picture color science. I’ve spoken at conferences for both sets of technologies.
ICC and ACES are for different industries and solve different issues.
ICC is both a color management architecture and color management system. It’s similar to ACES+OCIO.
As color management systems they have a lot in common. The new ICC max format removes most of the print centric limitations from the past.
While ICC was paper bound, color science for motion pictures was film bound. IIF which was renamed ACES was a film centric workflow and design. So while ICC originally was based around a d50 white of print shops, ACES used a D60 that was a compromise between film white and video white.
It’s hard to over state the speed and capability difference that has happened over my time in the industry especially for rendering. From my time beginning in ACES Most color transformations were done were exceptionally optimized. Most were 1-d luts that were optimized for use, so 8,10,12 and 16 bit 1-d tables were benchmarked against render time. The fastest systems were still significantly integer based. Results were written directly to and from the graphics cards. The ICC framework was impossibly processor intensive for that application.
However going the other way was a non-issue. Making copies of the motion picture pipeline that could be used in ICC is pretty trivial. This is why OCIO has bakeicc commands. You can have matte painters and visualization artists work in native colorspaces via ICC.
Color management in motion pictures is still in its infancy. It’s catching up quickly but ICC style color management benefited from additional decades of implementation and development. As well since it can be used in mass market devices there is a volume of support and money that ACES will be challenged to meet.
A quick gut check for this can be had even in products targeted towards motion picture processionals. Prorez raw launched without an ACES output function, but nearly every Apple product uses and supports ICC.
Thanks for the post Joseph …
I think you make some great points, but I want to add a few points for clarity.
While I understand your point, I just want to clarify for others who may be less familiar with ACES and ICC that there’s no “film color science” built into ACES. We often hear that ACES has a very filmic aesthetic. Some like it, some don’t, but the ACES 1.0 Output Transforms aren’t film models.
ACES, like film, does leverage the concept of image states architectures. This just means that ACES files are scene referred, retain as much dynamic range as possible from the original scene, and reproduce some subset of that dynamic range on a display. This is similar in concept to the way film negatives have a wide dynamic range of which only a subset makes it onto the print stock.
ICC was originally designed for cross-media color management and is most comfortable taking one device dependent output referred image and transforming it to another set of device dependent output referred code values for reproducing the image on an different output device. ICC doesn’t really have the concept image states architectures built-in. It has been adapted over the years to deal with scene referred images, but it’s not it’s natural workflow.
I think it’s also important to clarify that ICC uses the concept of a Profile Connection Space (PCS) which has a reference medium, with a D50 based device independent color encoding, a reference viewing environment, and a reference gamut boundary.
While this may sound similar to ACES, it’s actually very different. ACES doesn’t use a PCS and has no reference medium. As part of the ACES 2065-1 color encoding specification, equal RGB values are defined as having a chromaticity of about the chromaticity of D60, but this is for the purpose of having context building transforms into and out of the ACES 2065-1 encoding. There’s nothing lossy about going into ACES 2065-1 and your neutrals don’t have to have the ACES white point.
ICC PCS, however, is lossy. The dynamic range, in particular, is limited to the dynamic range of the PCS reference medium (a dynamic range of 288:1). There are ways to work around these limitation using the ICC system, but this is the default and by far most common ICC workflow. This is a problem not only for motion picture production, but HDR color management in general. The ICC recognizes this and has a working group investigating what modifications they would need to make the architecture to address HDR workflows.
In summary, I think you’re 100% correct in saying “ICC and ACES are for different industries and solve different issues.” I just wanted to provide more specifics for those who aren’t as familiar with color management or ICC as those of us with backgrounds in printing technology from RIT
Alex what I meant by film color science is that ACES was designed literally around physical film negative and print as ICC was initially designed around paper. Both have evolved beyond that, but that was the history.
There is some hair splitting going on to say that ACES doesn’t have a PCS. It has a defined white chromaticity, a defined gamut,OCES, and a reference grey luminance of .18. The RRT is designed to be pleasing representation of the source imagery that sits at the cross between input and viewing colorspaces that defines the transition from ACES to OCES. There isn’t much practical difference between the ICC PCS and the ACES RRT. The use of a profile connection space is not inherently lossy or bad. It’s just a tool in a color management system.
Hello Brian and welcome,
I have been pretty vocal on this forum about ACES and some limitations, for example in this post.
Just like you, back in 2017, I had no clue about colour as you can tell in my first post. And it is partly thanks to this community that I started and still continue this amazing journey through colour. To answer your question shortly, I would say that yes, these complaints have practical validity. Let me give a few examples :
- Image a system that clips shadow values in SDR at 0.002.
- Imagine a full CG character such as a red plumber lit by the sun… And his hat goes “Dorito” orange.
- Imagine a full CG light saber where the colour is an ACEScg primary and the character looks flat.
- Imagine a blue rabbit or sphere that goes purple when lit.
I think it goes back to Vlad’ s point : there is a lack of overall color science knowledge in the CG industry. Learning about colour science has made me a better lighting artist and now that I have seen and experienced first hand the “notorious 6”, I cannot go back to ACES 1.X. I have setup some trainings at the studio, so every artist knows what the “notorious 6” are and how to identify them.
It took me 15 years of experience to learn about “display transforms” and in my quest about colour, I have talked to many Lighting/Compositing/CG/VFX Supervisors and realized that most of them do not have a good understanding of what happens when the “image data” is rendered for a display device. So I agree with Joseph when he says that “color management in motion pictures is still in its infancy”.
I would say that the hue shifts/skews themselves are “not necessarily” the issue (as Alex explained). The issue is that with ACES, you will always get the same ones. So, maybe your different projects have different artistic needs but ACES will prevent you from having different behaviours. Your orange tones will always become “rat piss yellow” with values above 1 for instance.
As Derek and Thomas have explained, part of the issue comes from per-channel. We could add that ARRI K1S1 is a per-channel display transform that has been used massively and with great success. So, in reality, the issue is not per-channel itself but how it is implemented (as explained brilliantly in this post by Jed). You can also have a look at this cool post about per-channel by Alex Tardif.
As always, devil is in the details. I don’ t know what is the scope of your projects, if you display in SDR or HDR and what are your requirements. Many artists who just want an “automatic tone mapper” use ACES because it has been implemented in most DCC softwares (ACES being like the lowest common denominator here) and they got used over the years to the “notorious 6 aesthetics”. But once you have seen differently, there is no going back.
About ACES productions, I would be very careful because it has been said by different people in several meetings that the ACES Output Transforms were inverted most/all of the time. So I will stick to what I know : ACES is mostly used for exchanging files and archival (unless proven otherwise).
Finally, about openness and transparency, I wish the TAC would have let Daniele speak a year ago to present the Meta framework idea. And I also wish the TAC had discussed in their latest meeting the loss of their main contributor. I think that is a big deal. Sure, this community has a voice here on this forum and this is great. But is this voice being heard ? I am not sure.
I hope my criticism is constructive. As Vlad explains, part of the issue is the “ACES evangelist” (I used to be one of them) and as a community, we need to dig deeper and expand the knowledge. So artists can take better decisions and not just follow a trend.
On the subject of ICC, I’d to be curious to hear folks thoughts on Adobe Substance 3D Painter’s new ACE color system which is based on ICC and has ACEScg as one of its working spaces.
Maybe Adobe will save us. They know color and they know how to get stuff done, so maybe!
In the meantime, it seems like the problems that Christophe describes are long-standing and unresolved and there’s no alternative standard to switch to. I’m happy with my ACES workflow, but the specter of Something being Wrong is troubling, for sure.
I’m looking forward to the official release of ACES 2.0 (is that what it will be called?). The candidates are looking very good, especially C (hint hint ).
EDIT: As @ChrisBrejon points out below, these were mistakenly done with an older version of the Candidates OCIO config, so the current Candidate A does not in fact have these issues shown below.
Regarding those skews (blue to magenta for example) here’s an image from @ChrisBrejon viewed in ACES 1.2 where you can this pretty clearly:
Here’s that image with Candidate A. Not much change as far as those colors go.
Here’s Candidate B. The skews are gone.
Same with candidate C.
So of the candidates, only B & C address these color skews. If these were a “must have” (personally, I feel similar to @ChrisBrejon that they are) then that disqualifies A for me.
Just for funsies, here’s ACES 1.2 with the Gamut Compression applied from ACES 1.3. Not perfect, but way better on those blues not going so magenta.
Very nice! Candidate C is
6 posts were split to a new topic: OT Candidates discussion
Until they fix shift to magenta and 8 BIT PRORES on export and incorrect colors with prores source files from alexa cameras on import, I personally doubt it.
I’m tired of instructing vfx-artists how to deal with all these bugs, so they could send me high bit depth files back without any change in colors.
It has per channel tone (highlights mostly) mapping, then primaries conversion of the tone-mapped image, then linear-to-rec709 (not gamma2.4) encoding. So, how it affects out-of-gamut colors depends on source gamut.
Joseph, respectfully I have to disagree with your analogy between ICC PCS and the ACES system.
The PCS very much is inherently lossy where ACES 2065-1 re-encodes the scene colorimetry using a standard color encoding and set of viewing conditions. It does not impose a reference medium the way ICC PCS does. This has a huge practical effect.
The ICC PCS reference medium is based on the colorimetry of a reflection print with a very low dynamic range. This is devastating to scene referred images and output to HDR devices. Again, there’s various strategies that people use to try to work around the issue, but the system is inherently limited and trying to use it with image states based workflows and HDR are a bit of square peg in a round hole. The only analogy I can think of would be if the ACES 2065-1 were based on the colorimetry of an image as displayed on a traditional broadcast display with a dynamic range of ~300:1. That would be highly problematic for modern motion picture, television and gaming workflows.
ICC Max is a different beast that I can’t speak to.
Below is a quote from the ICC with camera images white paper.
ICC color management workflows generally assume that the colorimetry
expressed in the PCS is of a [color-rendered] picture, and not of a scene. There
is currently no mechanism to indicate that the colorimetry represented in the PCS
by a camera profile is relative scene colorimetry. Even if there were, use of the
PCS to contain relative scene colorimetry is not fully compatible with current ICC
workflows, which assume color rendering has been performed. This distinction is
especially important with respect to highlight reproduction. Many scenes contain
highlights that are brighter than the tone in the scene that is reproduced as white
in a picture. An important part of the color rendering process is selection of the
tone in the scene that is considered “edge of white”, and graceful compression of
brighter tones to fit on the reproduction medium (between the “edge of white”
tone and the medium white).
An ICC working group has been formed to attempt to address issues with the use
of ICC profiles in digital photography applications, but at present progress is
difficult. Even if improved characterization targets (such as narrow-band emissive
targets) and profiling tools are introduced, colorimetric intents will still be
illumination specific, and perceptual intents will optimally be scene-specific.
Some argue that scene-to-picture color rendering should be restricted to in-
camera processing and camera raw processing applications, and correction of
color rendering deficiencies limited to image editing applications.
I guess we are just disagreeing on terminology. Every aspect of a PCS is implemented and defined in ACES and is used in the display pipeline. OCES has a preferential color manipulation, reference viewing condition, whitepoint, defined dynamic range and gamut. The specifications defining AMPAS are different then ones made for ICC but functionally it serves the same purpose in color management.
I’m point this out more to show that ACES follows established and proven aspects of successful color management systems.
As you noted other parts of ACES, such as IDT’s are different.
I’ve only kept aware of IccMax and haven’t seen how it works in practice.
The parts that interested me are that ICC max extends out the ability of ICC to use spectral data as well as material properties such as florescence. The ability to handle scene referred data is added by defining the conditions of the environment. So for an image with a 10,000 nit d65 white point, the white value is still 1,1,1, but that is defined in reference to the 10,000 nit d65. If not defined it defaults back to the historic specifications. There is a lot more in there as well.
I’m not stating the new capacity is the same as ACES, but it’s not an apples to oranges comparison.
OCES is a deprecated term. It’s not used in the HDR output transforms or in the candidate ACES 2.0 transforms. If you consider OCES an equivalent of ICC PCS, in the ACES system there’s still a way into it for scene referred data. That’s not the case with ICC PCS. ICC PCS reference medium is a least common denominator. OCES is the complete opposite and is intended to encapsulate all current and future displays.
In ACES the flow is always more information down to less information. With ICC PCS you’re sometimes forced to go from more information, to less information, to a location where you wish you had access to the original but PCS tossed it away.
I’m not trying to diminish ICC, but it’s a hammer when the motion picture industry needs a Torx screwdriver. You might be able to hit that Torx screw hard enough with the hammer to kinda get it to stick, but it’s not the right tool for the job.
All that has happened, again, because the actual mechanic is per channel, is punt the medium down the road.
The image formed is medium to medium, and no image constancy exists.
Sorry Troy. Not following. What’s “per channel?” This isn’t about the rendering. The reference medium in ICC is really just a definition of dynamic range limitations into which the colorimetry must fit.
Feeling like we are getting way off topic. I may split this tread into it’s how topic.
Of course it is about the rendering.
I think it is worth drawing attention to the idea that ICC protocols are essentially about replicating imagery. In ACES, there’s no clear acknowledgement that there is an image, despite the fact that it is already happening.
From the standpoint of the working space, there are fit colourimetry values. Call those W. They have singular definitions.
Then, the rendering comes along and throws all of that out, and there ends up being an implicit medium; ACES primaries, with colourimetry that is completely distorted from the origin colourimetry. That’s the per channel, and that is the picture. Were we in an ICC chain, that’s the thing we’d be replicating.
This isn’t a bad thing, it just is drawing attention to the fact that there is always a medium. From the standpoint of what people see. In this case, it just happens that there’s accidental distortions between every medium, hence ends up being arbitrary. This is why the HDR and SDR looks different, and SDR to SDR looks different.
Going off the deep end about colourimetry in the working space is nonsense when none of it matters due to the arbitrary distortions happening on the output. Literally none of it, except achromatic values, makes it out as the colourimetry stands in the origin.
Good catch Chris! Indeed I was mistakenly using an older OCIO (rev007) so Candidate A was… something else. I think it was at the time just ACES 1.x with the MM tone scale and removed sweeteners. I guess that’s what you get for doing blind testing!
Everyone: Please disregard all my comments about Candidate A in this thread.