We’re starting a new project and doing pipeline tests.
Shots are Sony linear, but when we generate QT’s, both Fusion and Nuke are identical to the reference QT the clients have sent, however, Flames version is slightly off, warmer and more saturated. I have tried in 2022 and 2023, Linux and Mac
It`s hard to tell, without digging deep, but what kind of color policies you use in all three apps? By default Nuke and Fusion is using plane linear color pipeline, Flame could be set to ACES
2 Likes
No, non ACES project, nothing untoward.
It looks like qt gamma shift. @finnjaeger we need your superpower
With what device are you comparing the clients qt to the flame’s? Do you have ColourSync enabled when you export the qt from flame?
Even before its exported, you can see the colour difference, which is very subtle.
So with sony linear you mean sony XOCN? Or Sony raw? Or is it linear/Slog3?
elaborate on your viewing and rendering pipeline here, if you work with linear plates and you write QTs that means you apply some kind of display transform like linear->slog3->LUT or whatever? Lots of places where this could go wrong.
Also obviously need to take in acocunt stuff like flames viewer and colormanagement rules what you see might not be what you get.
If its sony raw/XOCN make sure debayer settings are matching across programs as well.
Warmer and more saturated sounds like sgamut3.cine vs sgamut3 or something like that?
1 Like
Not a gamma shift, i can compensate with a red, blue and saturation tweak.
Updated my post, kinda sounds like sgamut3.cine vs sgamut3 if you are talking sony?
1 Like
Yes, but they have specified gamut3.cine
So, I’ve just tried the SGamut3 transform and the colour is spot on, which I find odd as they have specified SGamut3.cine.
Is it possible that they are labelled incorrectly in Flame?
1 Like
I’ve done lots of SGamut3.cine and it has always been identical in Resolve and Flame. More likely they told you the wrong thing, or everyone else is handling it incorrectly (which I have definitely experienced before).
5 Likes
which one is better when shooting sony anyhow?
.cine is the smaller but most people choose that one for whatever reason?
Should be able to change it to something else if the source is sony raw or xocn as well…
It makes sense to use Cine when finishing for HDR or cinema as the gamut is only slightly wider than P3 so no wasted data. You are maximising your use of numbers to fit what you’re delivering.
If you were actually grading in Rec2020, which I don’t believe anyone is, then you wouldn’t use S-Gamut3.cine, you’d use S-Gamut3. As it is closer to/ slightly wider than Rec2020 in width. I guess to future proof it?
Yea that seems like it especially for lower bit depth capture or lower bitdepth intermediates
Seems to be redundant if you have raw capture or are going to 16bit float , sonyraw is 16bit integer linear, always capturing native sensor gamut of course (which apparently is more like sgamut). So what usecase is there for the venice2 then?
you arent gaining more precission, (ok well maybe very very slightly, but I would argue that in 16bf its not relevant) and if you go to Linear/ACES it wont matter at all anymore, just that the sgamut3.cine could potentionally clip values that the sgamut.3 could still capture?
Just seema kinda odd that sony would create 2 different gamuts for slog3 vs arri and red etc just having one, especially red is waisting massive amounts of values in the greens.
1 Like
There would definitely be more precision in a log workflow looking to grade/Finish in a P3 gamut. As to how much extra precision in a real world scenario, who knows?!! Seems to be as much of a feel/response for colourists as much as anything
The second you are working in ACES linear 16bit float then it doesn’t really matter.
Yea you mean when you comp on log or render log from comp… then yes sorry i dont even think about those things anymore its been all that exr life for me for years now 
2 Likes