I think this CTF includes a primaries modification.
ACEScct
2 Likes
Yeah pretty sure “Interchange” is not just a gamma thing.
I actually always understood it as an “interchange” ie: to and from. So definitely not just gamma.
Why woild there also be a “gamma” section if that’s what interchange was?
The Output descriptor pretty much says it all.
And as Phill just said CTF includes primaries modifications.
Just a workflow
You are absolutely correct, and that’s my mistake.
ACES2065-1 is actually AP0, and not AP1.
Puts me back to square 1, as in the gamma section there is nothing available for ACEScct
Quick workflow question @allklier
Have you tried using your Luts inside Image with the Color Management matchbox?
Or is it not very usable?
I’ve actually never used it and thought this might be one of the scenarios which one might use it?
Good question. Might be an interesting workflow…
Add a selective (which then you can move up and down in the priority), remove the MasterGrade and replace with ColorMgmt matchbox for including a LUT.
Still would have to sandwich it with transforms to make sure the LUT has the right input/ouptut.
But it would certainly be equivalent to using ColorMgmt in TL-FX and then keeps that slot open for something else.
1 Like
Cool yeah, I think I’ll give it try it out. See how it goes speed wise and logic in the brain wise.
Seems like the ambiguity of the labeling of these ACES transforms goes way back to AMPAS.
Here’s the official transform: aces-core/transforms/ctl/csc/ACEScct/ACEScsc.ACES_to_ACEScct.ctl at v1.0.3 · ampas/aces-core · GitHub
Labeled ACES to ACEScct, but if you read the fine print it does ACES2065-1 to ACEScct. Starting with an AP0 to AP1 matrix, and then a math transform instead of a 1D LUT.
Actually the solution may be this one:
Based on reading the actual ctf file, it removes gamma 2.4 and applies matrix to ACES2065-1.
What’s odd is that the sRGB CTF removes a 2.4 gamma, while BT.709 CTF removes a 2.2 gamma, which seems like the inverse of what it should be??
Don’t trust labels. Trust math.
This is way harder than it should be.
<?xml version="1.0" encoding="UTF-8"?>
<ProcessList id="interchange/sRGB/untonemapped_sRGB_to_ACES" name="sRGB (untonemapped)" version="1.3">
<Info version="2.0">
<Release>2019.1.84</Release>
<Copyright>Copyright 2024 Autodesk, Inc. All rights reserved.</Copyright>
<Category>
<Hierarchy>Textures</Hierarchy>
<UserFacingName>sRGB</UserFacingName>
<Tags>
<Flame />
<Maya />
<Input />
<InputTagOnly />
</Tags>
</Category>
<InputSpace>
<ImageState>video</ImageState>
<ShortName>sRGB</ShortName>
<ID>sRGB</ID>
</InputSpace>
<OutputSpace>
<ImageState>scene</ImageState>
<ShortName>ACES2065-1</ShortName>
<ID>1</ID>
</OutputSpace>
</Info>
<Description>Gamma-encoded sRGB to scene-linear values -- no inverse tone-mapping.</Description>
<InputDescriptor>gamma-encoded RGB (sRGB primaries)</InputDescriptor>
<OutputDescriptor>ACES</OutputDescriptor>
<Gamma inBitDepth="12i" outBitDepth="16f" style="moncurveFwd">
<GammaParams gamma="2.400000000000000" offset="0.055000" />
</Gamma>
<Matrix inBitDepth="16f" outBitDepth="16f">
<Description>sRGB to ACES matrix</Description>
<Array dim="3 3 3">
0.4395756721 0.3839125931 0.1765117198
0.0896003842 0.8147141337 0.0956854597
0.0174154826 0.1087343544 0.8738501668
</Array>
</Matrix>
</ProcessList>
This is the way!
2 Likes
Has the added benefit of giving them opacity controls. You wouldn’t want that with a color space conversion, but you sure might on your 5229 emulation.
2 Likes
Oh yea usually all transforms are always from and to reference space which is Aces 2065-1 
Hence my question why the transform worked for acescg sources, obviosuly going 2065-1->acesCCt and then back to 2065-1 generates a no-op but the lut would still be applied in the wrong colorspace .
I dont think that works.
you would have to go acesCG to 2065-1 to acesCCt to lut to 20651 to acesCG . thats how most of these transforms actually
work same thing in ocio where you always talk “from” and “to” reference
btw what are you trying to do with sRGB sources dont make your life this hard with allready broken stuff lol
This was a test project where I used some Rec709 footage I had lying around.
In most cases it would some proper camera footage.
To your other question - when you tag sources, have working space set to ACEScg, and then add a ColorMgmt TL-FX, is an automatic conversion added, or does the ColorMgmt TL-FX work off the source directly?
the working space is automatically adapted to the background on default like action , image is action so if you add a geeen tlfx to acesCCt image working space sets itself to acesCCt , so no conversions
or maybe if i understand the question differently , the tlfx colormanagement works off the source directly.
In general when you tag anything in flame it does not get converted to workingspace ever - (technically in action it does but i have never seen that work right ever)
so you could tag your source as whatever you want and the tlfx colormanage would get the right values still.
Great - that clarifies.
If I have project working space ACEScg (the default profile when you configure the project), anything running inside Image node will be in linear, which is why an ACEScct LUT isn’t working.
However, if I put a ColorMgmt TLFX, it sees the the tagged source in original color, so it’s getting LogC/Rec709, etc. If the ColorMgmt is set to ‘From Source’ with ‘Rules’ it would act according to the tagging and color working space.
But if I use a custom transform and explicitly go from whatever the footage color space I tagged with towards ACEScct, do my LUT, and then go back either to the original, or in that case maybe straight to ACEScg, I have a proper chain.
And yes, understood that no conversion happens by default when you just tag. The only conversion that happens is during the render based on rules (if you enable the viewing transform, otherwise not even there).
In some ways that’s where Nuke and Resolve color management is easier. It has better transparency on when / where it happens.
yea but none of these have as good as a dynamic view transform setup and stuff.
OCIO is good , its so open and whatwver but hoenstly syncolor has grown on me a bunch! its so fast to setup a showgrade
2 Likes
Colour science is often explained in a way that is more complex than what it needs to be.
Would it be worth having a “Colour Science in Layman’s terms” Logik live?
Now I am going to make an admission here, I rarely, if ever, look at the Logik Live videos. When I have I usually on watch a few minutes then get interrupted and never get back to finishing them as there are other things to do. The above suggestion may have already been taken care of already as I didn’t watch any of the colour science episodes recently that I know @finnjaeger was a part of. Excusing my ignorance, is there a need or are there people out there who would like a simpler explanation of colour science, including for HDR? If you are hesitant to publicly ask for that then feel free to PM me. I’m not suggesting for one second that I am the oracle of colour science knowledge but if there is a genuine desire for the above then I can help make it happen.
1 Like
It’s a complex topic and it never hurts to revisit, as even folks that deal with it a lot will pick up nuggets that will make their day easier, or at least solve them with more confidence.
There are few separate angles…
There’s the basics of color science - the color spaces, what describes them, which ones you should use when, etc. That would include discussion on HDR presumably, and maybe Dolby Vision.
There’s how a particular application handles color management, which came up a lot in this thread. That can be a presentation in it’s own right.
You can take a separate journey into the debate and logic of scene referred vs. display referred, and why ACES (among other scene referred setups) exists and should be used.
And then there are the misc topics on tools and tricks - using LUTs properly, understanding tradeoffs between LUTs and transforms, inverse transforms, tone mapping, the recent discussions about EXR and linear vs. log in combination with compression.
The merits of Flame’s color management approach vs. other apps like Nuke.
Probably forgetting some…
Keep in mind that Finn did teach a color management class on Logik Academy Pro. Not sure of the details, but we may not want to step on toes there…
It really doesn’t need to be complex. I reckon more than 90% of Flame Artists would have the cognitive capacity to understand it if explained in the right way. I’ve managed to explain it in a way that junior Finishing Editors & VFX Artists have been able to understand.
I love the whole idea of Logik Academy. I don’t have an issue with anyone wanting to put that sort of knowledge behind a paywall and can appreciate wanting something in return (not suggesting for one second that someone like @finnjaeger is doing it for those reasons either as he happily and openly shares his opinion and knowledge on here). On the flip side, if someone wants to impart with their knowledge, and I am happy to do so, for free in a way that is openly accessible then I think that should also be supported and encouraged. One doesn’t need to exclude the other. I personally wish the Flame for Nuke Artists course was openly available as it may encourage more users but if I believe in something like that strongly enough, I could always make it myself and put it up on You Tube/Vimeo/Whatever. Being time poor is my current excuse.
The question remains though, is an openly accessible discussion/explanation of colour spaces and HDR something people are interested in?
I also think colour pipelines/workflow could be covered in that as well.
2 Likes
Thanks for logging an improvement for this and referencing the current discussion. We will improve the documentation and the various CTF so it is clear what they do.
4 Likes
I’d be down for this! I feel I have a functional understanding of colour management that works for me and the work I’m doing, able to solve most puzzles that come my way, but I legitimately enjoy a deeper understanding of concepts that not only clarifies jargon, but opens up further opportunities for troubleshooting on the fly. So yes, as I said, I’d definitely be down! And I don’t think anyone cares if there is community created content that competes with what’s on Logik Academy. If that were the case I’d be disappointed, but I’m fairly positive it is not.
3 Likes