Hi, one question, where I work we make Netflix standard films, and their standard is Aces 2065-1, when I convert to Aces CG I don’t have flames, I have more saturated colors, would this for chroma key cropping help? Sometimes I convert aces 2065-1 to cct and I get good cuts, but not always.
1 Like
ACES2065-1 is absolutely not a good place to do pretty much any work. It is intended and designed strictly for transport between facilities and archiving.
Use ACEScg or ACEScct/cc for work, depending on the task/node in which you are working.
If you want more details you can check this out as it goes into tons of detail on what to work on in what color space.
1 Like
Ooh, I missed this in your original post…
This means something is incorrect with your Viewing Rules. An image is an image. ACES is designed for every image (captured by a known camera, that is) to look visually the same so we can composite them. BUT, under the hood when you look at the raw pixel data, it is in fact different encoding of pixel values.
Using the correct viewing rules means your ACES2065-1 and ACEScg should look the same, and only look different when you bypass the viewport monitor.
I watched your video, it helped me a lot, sometimes I have small doubts, but the ACES2065-1 even leaving it in bypass when viewing in flame has horrible colors, of course my work monitor is rec 709, cct the image I see washed log, for chroma key It helps a lot, but I’m going to try to use it to convert it into cg aces and at the end of the comp go back to ACES2065-1, as I have to give it to the colorist in ACES2065-1
Yes, a color difference only appears when I use bypass the view monitor
1 Like
Good, that means its behavior correctly. You are correct…when bypassing the Viewing Rules by hitting the Bypass button, you are looking at raw pixel data. To be clear, you really don’t need to be looking at the raw pixel data for working, only for double checking you know what you have is correct.
Use the Viewing Rules as I’ve outlined at the beginning of the series and you’ll be fine.
Good luck!
1 Like
I have to push back on that a bit. In my experience working on episodic and long-form content for several of the major streaming platforms, ACES2065-1 has absolutely been the working format—not just for interchange or archiving.
We receive VFX specs directly from studios and streamers, and they routinely specify ACES2065-1 for ingest, delivery, and all intermediate steps. We work in ACES2065-1 throughout—using LUTs built for AP0, doing comp and look development in that space, and only converting to Rec.709 or similar for temp review or tracking. ACEScg only enters the pipeline when we’re integrating CG renders, and ACEScct/cc only gets used when grading or addressing edge cases like negative values.
So, to say it’s “absolutely not a good place” feels overly rigid and not reflective of actual high-end VFX workflows. If anything, many clients explicitly want to maintain maximum fidelity, especially for HDR workflows—so avoiding unnecessary conversions (like to ACEScg) is preferred to minimize any potential gamut clipping or data loss.
To be clear: I’m not trying to be argumentative. I just think this needs clarification, because others might wrongly assume that working in ACES2065-1 is incorrect or outdated—when in fact it’s still a core part of many studio-approved, modern pipelines.
2 Likes
From my understanding, if your working color space is ACES2065-1 and you’ve been supplied files in ACES2065-1, then importing them as ACEScg—without converting between the two—would understandably result in the image looking desaturated or off.
Please correct me if I’m mistaken, and I truly apologize if I’ve misunderstood anything. I say this with the utmost respect for your expertise.
Correct. ACES2065-1 (aka AP0) has different primaries from AP1 (cg, cc, cct, proxy)
If you don’t convert between the two, your color mapping (which pixel values represent which colors in CIE-XY will be factually incorrect).
But what Randy said is ‘if you use the correct viewing rules’, which refers to the matching transform, they will look the same, as they would apply the proper transform. So his statement is also correct with the ‘if’ he applied.
Meaning there would be a different transforms for AP0 and AP1.
As there’s not necessarily meta data, you may have to tag the files accordingly.
While it may sound pedestrian, I found that the ACES Wikipedia page is a very handy reference for ACES that is easier to decode than most way more technical documentation you can find: Academy Color Encoding System - Wikipedia
It has all the facts and no fluff. Scroll down to the ‘ACES Color Spaces’ section of the page.
1 Like
I was looking for an response on the right way in relation to colour mangement implementation in flame not ACES general knowledge, but thanks.
Not found a good resource for this yet, I was going to buy some tutorials just to confirm with my self and increase my confidence in flame CM, but read this thread and got put off.
1 Like
@mux Fair enough. I hadn’t read the whole thread from the top (should have).
On the original point - I think this would require more investigation. While technically a pipeline may work either way, and there’s a good argument for not throwing away precision if you don’t have to. There are three caveats, two of which are Flame specific:
- Are all the nodes working equally well in AP0 than in AP1 - things like keyers, etc? I believe I read that the origin of AP1 was to make it easier to work with some tools. That would require testing and comparison.
- Are the color spaces transforms/viewing rules that ship with Flame for AP0 as comprehensive as they are with AP1, or do you have to augment with your own? That would but a big burden, but is a one-time solve at the pipeline.
- Is the difference perceptual to warrant the effort. Kind of like the 13th bit debate on the Alexa35. And is the difference valuable to purists or the everyday practioner?
Also, may I ask—what is the intended idea or common practice here?
As I mentioned earlier, my understanding and experience suggest that some of the statements or solutions presented here may not reflect actual industry practice. I don’t believe they are entirely accurate or commonly followed, and I feel it’s important to clarify that—for the benefit of everyone, especially Flame artists who might be misled if my understanding is correct.
Of course, I’m open to being corrected if I’m mistaken, and I say all of this with full respect to everyone contributing. I do think this topic deserves to be revisited and discussed further to ensure we’re all aligned on best practices.
I’ve never seen AP0 as a working format.
Do you have to keep the bit depth at 32 bit? Do the clients notice if you don’t? Do they notice if you go into CCT and back? Do you have to give them a heads up if there are some ACEScg elements?
I’d probably just lie and work in aces CG.
Because at the end of the day, movies and TV aren’t good because they have colors that are nigh-invisible to the human eye. Nobody’s lamenting whatever colorspace Starship Troopers used.
But I mean, nobody listens to me. Instead the powers that be greenlight Rebel Moon and mandate an AP0 workflow. So I feel your pain, but I sincerely hope AP0 does not become industry standard.
2 Likes
Clients probably don’t notice but their QC dept that’s diff’ing everything with the originals at 3200% gain probably does.
2 Likes
definitely not the standard across most of my work but can confirm that I’ve had episodic projects come in that wanted everything AP0 top to bottom.
So far all my episodics (8 so far) are AP0 top to bottom, and one excuse given was for HDR.
And I actually dont have a problem working with it, infact I dont find it any different in any way.
In some cases I found that the exr’s supplied were tagged as ACEScg, but were actually AP0. Can get messy from the very beginning. But so far all the studio’s including Netflix want APO top to bottom from me.
And I dont have a problem with it.
@andy_dill 16bit, if the grade finds clipping in the whites, they will get back to you, and will probably redo it in AP0
1 Like
My question is do they ever do gamut kickbacks? Like “we’re seeing loss in extreme greens,” since that’s where the discrepancy between AP0 and AP1 resides.
Clipped whites are a universal issue in any linear colorspace and wouldn’t be affected by the ACEScg primaries vs the 2065-1 primaries.
And I know we’re all just working whatever way people pay us to work, but I’ve always been fascinated by extreme standards adherence (client side). From Netflix mandating sensor density, to what constitutes an “illegal color” in broadcast, to how goddamn big a “scanline” is, there is so much obfuscated jargon pushed by people who just heard it from someone else.
2 Likes
I’m not sure myself, like you said, I get payed for it and probably keeps me in work with that client/studio, ..but for me I dont find any issue working in AP0 so why downgrade it? you can convert it need be to as I said above..
I suppose its like,. why work in 8k when your delivering 4k or HD, why work in raw in flame rather than prores , .
…but the point of this thread is you can’t say “ACES2065-1 is absolutely not a good place to do pretty much any work” thats not true, its probably the most desired place to work, but maybe not efficient. I dont personallythink it makes a difference or more or less efficient, in fact I think flame tools may work better, maybe thats in my imagination, I only say that because most docs or all, …say work in AP1, …they must be written by cg people,..
On the other hand in flame I always chose Raw, still do,.., nothing less ( ie prores) when setting up a project, … how about you? AP0 is rawer right?
Maybe the studios know something thats not documented and want us to work in AP0, there’s to be a good reason.
ah. not what I am saying.
All I was saying was an image encoded in different color spaces look identical when tagged correctly and viewed correctly.
2 Likes
I have never seen anywhere that a streamer will want you to work in ACES AP0. Where have you seen that?!! I work with all the big studios and I have never seen that recommendation ever, in fact, quite opposite. ACES even stipulates that ACES 2065-1 (AP0) is intended only as a transport colourspace and that you should only ever work in AP1 (ACEScg/ACEScc/ACEScct). I will actually even go as far as saying that if a major studio/streamer knew you were working in AP0 that they would have an issue with it.
There are good reasons why you don’t want to work in AP0. First of all, the gamut is way beyond anything any monitor can display. So you could be creating values you can’t see which will create clipping when you reach the extremities. Bad idea. A key could look good on your monitor now but down the track when Rec2020 capable displays actually become available you could have a whole lot of noise in them that you can’t see. Same goes for CG renders.
As for losing information, sure in Flame it is possible. Most other applications are actually working in 32bit so there is no loss in a colour space transform between AP0 to other colour spaces and back. The loss is so minimal in Flame that there would be no reason to avoid it.
Sure, if you want to go against all the technical advice against working in 2065-1 then go for it but it is not best practice.
3 Likes