Playing with Flame on the XDR capable macbook pro in Rec709 reference mode seeign how flame handles it or doesnt.
→ Set macbook to rec709/Bt.1886 reference mode
→ Set Flame to “sync with OS”
What is flame pushing to macOS as metadata of what those pixels in the viewer are? I would expect that to be “rec709” or 1-1-1 in quicktime terms, just like what FCPX is doing. but that does not seem to be the case, that leads to that there is no match between quicktime and flame viewer in any circumstance with the XDR - SDR reference mode. It also seems to try to do something weird, that it should not do, as the saturation is also different.
for reference - resolve matches FCPX behaviour once the timeline colorspace is set to rec709-A which i also find weird, why isnt it rec709(scene) as the resulting metdata on render is … the same and thats without any colormanagement in resolve oO. (1-1-1)
(top is flame viewer, below is fcpx) i know screenshots on a colormanaged macbook arent ideal but it gets the mismatch across.
This is in a aces project with properly tagged sources, same in legacy/untagged
I feel like there is something inherently wrong with how flame handles macOS colormanagement, its trying to do stuff it shouldnt, like emulating something on top of macOS to “trick” it into showing something that matches with a broadcast monitor even though with XDR thats redundant and thus it all breaks.
Flame viewer only matches a wrongly tagged quicktime as 1-2-1 / gamma 2.4 when I activate the viewer process in flame, the colorsync compatible button should be removed as it does nothing but harm on XDR displays , as it will just display utterly wrong stuff. but I cant get it to match a 1-1-1 quicktime in XDR reference mode, which it should be doing.
2 Likes
Hi @finnjaeger,
The “Sync with OS” button in the Colour Management Preferences was intended to allow the use of monitors that are characterized with ICC-based tools and that do not match a standard reference calibration. (In other words, the monitor has a unique gamut or gamma which does not correspond to a standard and is compensated by its custom ICC profile.) A Flame Display Colour Space is created based on the ICC profile for the monitor.
In the case of Apple XDR monitors, you should not use the “Sync with OS” button for two reasons. First, Apple does not use ICC-based colour management for their XDR monitors (as is evident from the different UI in the MacOS Display Preferences for these monitors). Second, Apple provides you with a list of standard calibration aims to select from and so it’s easy to choose one that matches one of the standard Flame Display Colour Space options.
Typically I recommend people with XDR monitors choose the “HDR Video (P3-ST 2084)” preset and in Flame Setup enable the “HDR” check box for that display.
We will update the user manual to clarify this. Thanks for the feedback,
Doug
2 Likes
Hi @finnjaeger, here are the instructions to properly setup your Apple Pro XDR Display using Flame 2023 (or later versions): Help
1 Like
thanks all, good to know that this isnt icc based and that sync with os is not supposed to be used!
All the xdr setup however relates to HDR monitoring, I just want to monitor rec709 properly using the rec709 bt.1886 reference mode preset, I would expect flame viewer to - in this case display the same as quicktime with a file tagged as 1-1-1/ rec 709, just like how fcpx works.
so without sync to OS , i would set xdr to bt.1886 reference mode and then set flame graphics colorspace to rec709(or bypass the viewer process) , that should in theory just completely be a no-op from file pixel values to screen, right? but it is not, thats whats confusing me, what am I looking at? is flame reporting the viewer pixels as sRGB to the OS like it does with the rest of the UI elements?
also, I dont have one but the studio display iirc has reference mode for sdr but no hdr option. its like “semi xdr”
1 Like
Hi @finnjaeger,
Flame and Quicktime Player are different subjects that we should consider separately. For Flame, if you use the preset “HDTV Video (BT.709-BT.1886)” in MacOS Display Prefs and then select “Rec.709 video” as your Display Colour Space in Flame CM Preferences, that should work. If you have something tagged as Rec.709 video and hit Bypass, the viewport image should not change. And, most importantly, it should match a Rec.709 image on a real external Rec.709 broadcast monitor. (That should be the test, not whether it matches Quicktime Player.)
For Quicktime Player, there are many threads on the web discussing the many challenges getting the desired results with that app. Typically, if you use the “ColorSync Compatible” button when exporting from Flame, the Rec.709 output will look correct in Quicktime Player (it uses the 1-2-1 tagging). EXCEPT, unfortunately, if you are on an XDR monitor using the HDTV preset in your MacOS Display Prefs. For some reason, in that case, Quicktime Player works better with the 1-1-1 tagging and so you should turn off the “ColorSync Compatible” button in Flame. For the other XDR presets, the 1-2-1 tagging works better in Quicktime Player. (This is all very annoying since one would normally expect that Quicktime Player’s colour management would compensate for the Display preset so that a clip with a given tag would not appear to change. And that is mostly true except for that one preset, it seems.)
At least, that is what I’m seeing here on a Macbook Pro laptop with the XDR display. If you’re not seeing that, I would suggest you open a support case and we will ask for more information about how to reproduce what you’re seeing.
thanks,
Doug
2 Likes
Yea so I know about the whole colorsync compatible mess, and i know what flame is trying to do with lets call it “legacy” icc displays, and the 1-2-1 / gamma 2.4 “hack” and that matches flames UI, thats all good and dandy
its actually all on purpose by apple to solve the surround illumination and difference in high luminance displays so 1-1-1 is what we should always write as 1-2-1 is a inconsitent hack but thats a different discussion… 
What I did when i got my hands on the macbook xdr is i took a probe and measured the response of quicktime in reference mode with a 1-1-1 quicktime (measured a ramp of black->white patches and some basic primary charts using colorspace cms) and it was exactly gamma 2.4 and pretty much hit all the rec709 targets for primary and secondary colors, so basically verified qt the be correct.
So that leads me to the believe that quicktime with 1-1-1 files is in fact correct, which makes flame wrong as they differ , now once I am back home in a few weeks I am happy to re-measure and run patches through the flame UI , but i do believe that there is something off.
FCPX and resolve both match QT exactly.
Oh and btw you can create a new preset and turn on/off the “1.22 gamma boost” thats why its just happening in the rec709 preset, PN me your email I have some further deep talk regarding why apple does this that you might be interested in 
1 Like
so further testing:
Flame UI matches quicktime with a prores set to 1-13-1 (sRGB transfer function) .
So I would call my suspicion that it is in fact sending the same metadata as the rest of the flame UI to MacOS correct, while FCPX and Resolve both send the correct rec709 metadata to MacOS.
Did some more testing mostly in resolve with the BT1886/HDTV reference mode and the behaviour matches flame.
in resolve we have the option of running testpatches from colorspace and measure stuff with a probe.
This is what Resolve and Flame do in HDTV reference mode on a mac XDR display with “use mac profiles…” turned OFF, it ends up beign gamma 2.6, not 2.4.
Why? I think it just proofs my theory that it will assume the viewers pixels are sRGB(gamma 2.2)
2.2-> linear → 1.961*1.22 Boost = 2.6
if I change resolve to “turn mac profile” On and select rec709 as my “output colorspace” I end up at exactly 2.4 Gamma.
I am too lazy to run manual test patches through flame but its the same behaviour.
I think flame should report the whole UI to colorsync as beign gamma 1.961 … or something idk it doesnt work like how it is now .
