Hi everyone
I am using some down time to try to get to grips with workflow for colour in Flame and I am posting in desperate need of help before I go insane! I appreciate I am dragging up another old topic of Flame colour management and Quicktime. Take a look at the attached and you’ll see my issues immediately!
My question is what am I doing wrong and why is any image from Flame once shown in Quicktime or anything supported by Quicktime so different and what is the correct way to do this?
Here is my workflow:
R3D conformed in Resolve, tagged correctly and output as ProRes422HQ for Flame.
Why do it this way? Because I am sick of Flame’s Color Management Workflow and yes that is down to a lack of knowledge on my part.
Bring into Flame, Colour in batch and do all the other beauty work etc.
Export via MediaHub to ProRes422HQ
The screen grab shows the exact same file shown in 4 different systems (Flame, Resolve, Quicktime and Frame.io). Despite the small differences the image should look as it does in the top two noted “Flame” and “Resolve”. The bottom two are how the very same file looks in Quicktime and Frame.io or, more importantly, how my client sees it which is completely different to how it was graded.
Here is the Quicktime with all the metadata shown if this is helpful.
I don’t want to discourage you but trying to chase parity viewing on all systems is a fools game. Especially when you are dealing with colour managed and non colour managed programes. You mention frame.io but that could look one way on chrome and another on safari or firefox.
You are going to be grading log and you will preserve more information (10-bit vs 12-bit) in a 4444 XQ than you will in 422HQ although log is incredibly versatile.
How do you compare exported movies? nclc tagging will show same result reimported in flame. It’s only show some change opening the movie in QT in macos.
I helped in making this post a little bit, this whole quicktime thing is sort of my specialty for better or for worse.
you need to understand the underlyings namely “colorsync”,
most likely your flame viewer is wrong, your resolve viewer is wrong, quicktime is wrong, everything is wrong all the time, hell your screenshots might be wrong too ! macOS is the most complex OS for color management.
Colorsync works like ACES or any other colormanagement system , it has a input transform a working space and a output space, thats the very core of what you are seeign happening here!
Every single pixel on your machine is colormanaged by macOS so it gets “tagged” as what it is, your webbrowser, your flame GUI, resolve GUi, quicktime EVERYTHING gets a tag, can you read that tag - no you cant thanks apple.
this all gets converted to linear/XYZ internally thats colorsyncs working space thats where they mix colors and do their HDR shenaigans with EDR and everything, thats all under the hood
then the last part is the output or display transform, that depends on your MacOS display system settings.
then you have XDR on top of that that will change the physical response of your display as well and comes with reference modes.
its a pretty complex topic, have fun with the rabbit hole .
some examples:
You have a quicktime tagged correctly as 1-1-1 (everything else is WRONG for SDR) .
You set your monitor to gamma 2.4/rec709 in its own GUI settings (or use XDR rec709 reference mode)
you set macOS display to rec709 (or use XDR rec709 reference mode)
now your quicktime will show correctly in quicktime and it will give you referece response so it will match your reference monitor and we can show the maths why that happens :
NonXDR :
Step 1:
rec709 input gets linearized using 1.961 gamma
Step 2:
Linear data gets gamma 1.961 applied
Step3:
Data is beign thrown onto gamma 2.4 monitor
Result:
Step 1 and 2 cancel each other out , so your source signal stays as is.
but lets look at a common scenario, and most likely what you see in flame, this is what would happen on for example a macbook screen, depends on all your settings but this is very common for non-colorsync apps like flame :
Step 1:
rec709 input gets linearized using sRGB gamma and P3 Primaries as a source space (macOS default)
Step 2:
Linear data gets sRGB gamma and P3 primaries applied
Step3:
Data is beign thrown onto sRGB monitor with P3 Primaries (macbook display)
Result:
Step 1 and 2 cancel each other out , but now your rec709 content is beign shown “as is” on a P3 sRGB display, which does not match reference response and looks over-saturated.
Or lets look at a 1-2-1 tagged quicktime (2 means undefined, and there is a second gamma tag atom saying 2.4 most likely) :
Step 1:
rec709 input gets linearized using 2.4 gamma and rec709 color as a source space
Step 2:
Linear data gets sRGB gamma and P3 primaries applied
Step3:
Data is beign thrown onto sRGB monitor with P3 Primaries (macbook display)
Result: we removed the 2.4 gamma and applied a 2.2 (sRGB) gamma while taking care of the primaries, so this looks pretty close to reference, not exactly but close.
or 1-2-1 tagged QT on a rec709 monitor like a TV ;…
Step 1:
rec709 input gets linearized using 2.4 gamma and rec709 color as a source space
Step 2:
Linear data gets 1.961 gamma applied
Step3:
Data is beign thrown onto 2.4 gamma TV/reference monitor
Result: the image now has a total gamma of something like 2.6 and looks over contrasty.
as you can see all kinds of fun combinations.
My recommendation is to ALWAYS ALWAYS ALWAYS , tag everything, and i mean EVERYTHING , SDR as 1-1-1 rec709.
Once you upload something to any platform it gets re-encoded and stripped of metadata and you end up with inconsistent playback behaviour, with 1-1-1 its consinstent, as thats the ONLY valid SDR/HD video standard namely rec709, will it match your reference monitor? depends
on another note: iPad OS does this differently yet again
I am thanking you in advance of reading this @finnjaeger - you have always been an absolute LEGEND in sharing your knowledge here and I (and I am certain many others) are so grateful. I’m gonna finish my call, grab a BIG coffee and sit down with this asap!!! Thank you!!!
I always like to point out in these discussions, that in 1985, while we were tweeking out Time Base Correcters to make sure our 1" analog tape signals matched what we did the night before, aligned our peds and gains and chroma levels to a split on a switcher through a proc amp that may or may not have been tweeked since we last passed a video signal through it, we would say “one day this will be digital and all these problems will disappear.”
Hey everyone - so I am back again to gripe on colour. Can I ask how many of you out there colour grade in Flame? I have been doing so without issue since 2009. The last 3 years have been really challenging and I now have a very unhappy client because what looks great on my monitor here looks awful. healthy skintones in flame looks washed out and sickly when viewed in Quicktime. If I pull the same file into Premier or Resolve it looks great and matches the flame again. But when I look in Quicktime or upload to literally any service (I am using frame.io) it looks awful.
There HAS to be a work around I can’t get on board with just “explaining to the client” that this is what Quicktime does. They don’t care and nor should they.
Right now I am having them view via Blackmagic Web Presenter which is pulling the feed from my broadcast monitor into Zoom which actually looks very close but that doesn’t solve the issue of me providing it back to them and it looking liek shit.
This will be my last colour job unless I can figure this out.
There has to be a solution - what do you guys all do?
Thank you - sorry for ranting but this affects my reputation now and we all know how worrisome that can be! I’d be grateful for any solutions.
im assuming you are using some kind of rec709 viewing LUT in flame… are you making sure to bake that into your QT export? We work in ACEScg and use the flame color mgt “view transform” at the top of the timeline and post to FrameIO all the time with no issue.
