by the way , i had a friend call me because the whole tagging didnt work for him and we figured out he was still on OSX Mojave which apparently doesn’t differentiate between 1-2-1 and 1-1-1 in quicktime player which explains why this is a issue that has just been popping up. I dont know when(OR WHY) apple has done this but you know apple clicks a button and we all get a headache for months.
Even though It is the correct way of doing this imho.
I think this issue has been fixed in 2021.2.1.
Yes the latest version of Flame now supports correct tagging of quicktime files
Just installed 2021.2.1 and Flame is telling me now, that my quicktime is tagged 2-2-2. Shouldn’t it be 1-2-1 with a specification of gamma 2.4 in another column?
Really? That is specifying everything as undefined.
exactly. Does anybody see the same?
Did you turn on Color Sync?
Yup.
But honestly I didn’t checked a QT without colorsync enabled. Therefore I can’t really tell if there is a difference at all.
I was just wondering, why it is 2-2-2 now, where it was 1-1-1 in the previous release.
mine is 1-1-1 without, 1-2-1 with.
Okay, now Im confused…what should I be setting the Big Sur System Preferences / Display / Color to?
Rec 709 Gamma 2.4, right?
that’s what I have mine set to. If I look at a 1-2-1 and compare the QT to my flame output, It looks the same.
New day and now it works as expected 
Make a ProRes out of Flame, awesome…1-2-1, looks right. Make an h264 from that in Adobe Media Encoder, turns out 1-1-1, looks wrong. ARGH!
Whats the solve?
I tried to find a solution too but it looks like media encoder is not doing the right thing. There’s a lot of talk about in the forums too. I transcoded using Resolve and everything is right. . (the look and the numbers)
Thanks Adobe for giving me a reason to stop my subscription. I’m moving to resolve for all my transcodes now.
The AMCDX is great for anything not directly out of Flame, in order to change the tags. I haven’t upgraded to 2021.2.1 but I’ve been using the python script mentioned above to tag directly from Flame on mac, or opening the app and retagging there.
I recently ran into some hangups with this when delivering online content. There was a decision to bake in a LUT that matched the 1-2-1 look, in order for it to look “right” on Youtube, since Youtube ignores the tagging, from what I know. Problem is, if anyone watches on anything other than Safari, it looks wrong. So, we ended up baking in a ‘split the difference’ LUT, but the whole point here is, imo, changing to a 1-2-1 workflow doesn’t seem rock solid enough yet without global delivery support.
Curious if others have had successful workflows with 1-2-1 tagging through to delivery?
It’s starting to look like, for commercial work at least, we need to start to export two files. One for broadcast (1-2-1, 2.4 gamma) and another for online (1-1-1, 2.2 gamma). Personally I haven’t started to do this but the more we discuss this topic the more sense it makes.
The tagging only works on Macs and within ColorSync applications. While that might work for our clients, the moment it gets re-encoded all is lost. Even if YouTube, Vimeo, etc. started to support the tag, unless they do an actual color transform, then the tagging only works for Macs so those on Windows will still be seeing the wrong thing.
I really don’t love this idea since it’s a bit of a hassle and opens the door for a lot of confusion and potential mistakes beit operator error or client error. Back in the day it was so much simpler as we aimed for a broadcast monitor and that was it. How it looked on a srgb monitor was just chalked up to the difference between a fancy, expensive Sony CRT and your crappy laptop. But times they are a changin’ as the majority of our work goes online as opposed to broadcast so perhaps it’s time we adapt.
What I’d love to see if ADSK doing the leg work for us and give us an option for online delivery vs. broadcast. I’m not a color scientist and I’d like someone smarter than me to provide a rock solid solution based on concepts that are beyond me. Even if it’s as simple as removing 2.4 and applying 2.2 gamma, great…but then someone who is an expert in the area has made that call as opposed to us all doing our un-scientific tests and thinking that it’s correct. Basically I want an expert to say yes, this is how to do it and here’s a toggle for that. Filmlight seems to be doing a good job on that front but it’s definitely starting to get confusing and, weirdly, adding to insecurity if one is doing the right thing or not.
well said.
The only thing that kept me from going postal on that matter was “hdr is comming” … everything has a standard… absolute luminances…
And then apple came and destroyed HDR .
Someone just needs to shake some sense into the apple engineers thats really where the issues are… 1-1-1 should be gamma 2.4!
As long as there are no standards for web video we will never be even remotely sure how it looks on the receiving end.
https://www.apple.com/feedback/macos.html
feel free to tell apple that 1-1-1 should be gamma 2.4 
It’s nice that we have the correct meta data now on file exports for quicktime but I’ve just discovered that it gets stripped off if the file is transcoded into something else using Media Encoder. So I’m going back to the baked in lut for web.
So I’ve made a lut using the LOOK node and matched it to my calibrated monitor in the suite and the closest I got was setting the slope and saturation to 1.2. Its so close when you look at it on Frame.io and youtube. So now when I send a client to review I send them a baked in look for the web. The risky thing here is that if they use that file for broadcast tv.
Does anyone think this is a bad idea?
What you are doing isnto compensate for the shift from gamma 1.96->sRGB - sorta with the added thing of comparing your broadcast monitor thats gamma 2.4 in the same environment to your gui display, so now its all over the place.
But yea so they are no standards for any of this so if it makes your clients happy- sure why not The increase in saturation by 20% sounds a bit much to me however.
Also consider non colormanaged Operating systems like windows or iOS that dont have the 1.96->sRGB shift… just because it looks like X on your mac doesnt mean it looks like that on someone elses macbook (other set colorprofiles… different environment etc)
I am personally also sticking with untagged or 1-1-1 for the same reasons you said, it does not survive reencoding or web uploading, but I am only doing a slight gamma adjust from 2.4->2.2 on export. This is the middle ground for me between all the options.
I then do a webmaster in gamma 2.2 with the web sound and TV master in gamma 2.4 with R128 sound , for the agency person on a macbook in QT the TV master will look brighter and its easy to explain that macbooks are brighter hence the web master needs to be darker than the TV master (very simplified).
I also burn in that transform as a LUT onto my livestream and then tell people to use safari so the exported quicktime matches the livestream and that matches the reencode and web upload/playback internally on a given device .
-will it match on my gui screen .
-No.
Am i only trusting my reference monitor and disregard all other screens.
-Yes.
The main question is though - what do we want to display on someones device thats in some uncontrolled environment?
Old wisdom said the same exact pixels and the difference in gamma of the screens will take care of it but on MacOS - even if tagged correctly - it will not do that but is going for a different approach that is absolute luminance preserving - same as your approach - trying to match display X rendering to mastering display rendering as good as possible - flame also does this in its viewport - which makes sense if you have the screens next to each other (but then just maybe calibrate both to rec709/ BT.1886.)
Also consider that a macbook on full tilt brightness is like 500NIT while your reference screen is 100NIT… this change is way more significant than any minor gamma shift.
how I reached this conclusion is laid out nicely in this video, we did a buunch of research and there is no perfect solution but if you want to match some macbook in a office environment to a broadcast screen in a dark room you are going to have a really bad time…
There is no replacement for
looking at a reference screen in a reference environment when doing color decisions.