Is there anyway to talk the remote PCoIP monitor to being Rec709? I keep trying to switch it to Rec709 (that’s what I usually set my monitor at home at) and it always just quietly switches back to sRGB as soon as I close the control panel. So I have to keep switching my monitor around depending whether I working local, remote Linux Flame or Remote Mac.
could you elaborate where you set it to rec709?
there are ways to make sure you are getting a clean rec709 through remote tools etc, but it depends on the whole umage processing chain.
sRGB on macOS display setting would be fine, if flame is set to rec709 and “sync” turned off if your screen is actually rec709 
best way to probe what you actually get through all these screens and remote connections with a cheap probe and colourspace zro you can just measure patches and calculate the eotf
one thing that works in a local mac machine, you can use that as a baseline to what tour remote flame should
look like.
→ set flame to rec709 for GUI, turn sync with OS OFF, nake sure your source is tagged .
→ set your physical monitor to rec709 (gamma 2.4, 100nit)
→ set MacOS display setting to sRGB.
Why this works->
sync with OS off does not tell macOS what flame is doing so macOS colorsync will assume sRGB.
it will then transform sRGB to linear/XYZ
and theb transform linear/XYZ to sRGB (display)
which is a no-op so you get the same pixel values as in your flame GUI pushed to your display .
On Linux you dont have colorsync so nothing is beign messed with so you dont need to setup anything.
That is mostly what I do local except the MacOS display setting is Rec. ITU-R BT709-5 (I have a couple of 709s in there but they all seem to look the same.) Also the physical monitor is actually set to Rec1886 instead of 709 on the advice of a former boss who usually knows more than me. Quickly swapping between them doesn’t seem to look any different though.
stuff is super ill-named
bt1886 is the display standard for rec709 video, both should be 2.4 gamma there shoudl be a SLIGHT differences in the blacks as rec709 often refers to a “pure powerlaw” gamma 2.4 and bt1886 has a variable gamma curve depending on the archiveable blacklevel of the display, lots of opinions which is right .
If you keep your OS on rec709-5 , which is the correct choice for propelry colormanaged apps (like fcpx and quicktime) and your display on bt1886 you are golden - however flame is not one of those apps.
This is the same reason why i would say flame does not support XDR displays. If we cant have flame properly “tag” content to macOS as beign rec709 then the whole other part of macOS colormanagemebt falls on its face.
from my testing long ago with teradici and hp anyware to linux hosts- those too did not set any colormanagement tags so again macOS assumes sRGB with no gamut management so its all kinda of broken.
example what a local flame will do in your setup:
→ display is physically set to 2.4 gamma/rec709 primaries
→ flame is set to rec709 “sync with os” is off
→ MacOS system is set to rec709-5 (1.961 gamma)
Looking at gamma/EOTF only as gamut isnt changed anyhow for SDR;;
First Flame will create correct rec709 display reffered values in its GUI then sends them to macOS without any “tagging”
So now MacOS defaults to 1/sRGB to make it linear.
Then it goes from linear to 1.961 Gamma.
So we have a gamma 2.4 source * 1/2.2 * 1.961 = 2.13 if i am not mistaken , so you should be anle to measure something liek absolute gamma of 2.13 from your setup, switching it to sRGB on macOS system settings would get you net 2.4 BUT then quicktime wont be reference anymore , with your previous setup quicktime and fcpx with 1-1-1 tagged sources (colorsync compatible off) would give you reference response.
Its not possible to get flame to show the same as quicktime/fcpx when qt is playing back content tagged 1-1-1 without custom luts or other shenanigans.
chances are you have been looking at a wrong thing for X amount of years - and I am sure you are not alone!! macOS colormangement on top of another apps colormanagement can lead to big questionmarks and confusion.
How bright is the room you are sitting in? matbe 2.2 gamma would actually be more apropriate if 2.13 doesnt bother you …
I mean if the computer display is a bit off it’s not a disaster I guess, that’s the reason we have broadcast monitors after all, but this all seems kind of messier than it needs to be.
It’s not that bright a room if I close the blackout curtains, but sometimes I do leave them open for the cat.
I guess what I don’t really understand is why to leave the display set to sRGB and the physical monitor set to 2.4. Seems very counter intuitive to me.
1 Like
because colorsync is doing 2 transforms and it recognizes the flame UI as sRGB by default so by pivking sRGB gor the ICC/monitor profile we are “bypassing” macOS colormanagement.
as srgb → linear → sRGB does nothing.
If you could set flame up to correctly send “my content is rec709” to macOS this would be a non issue.
Do a test against broadcast monitor with this.
There are many other apps that are not properly “colorsync compatible” like nuke for example, the same thing applies, also for VLC player and some others (firefox used to be the same) .
I understand it sounds super weird and its not what apple wanted, i might find some time to make a custom view transform setup so we can match QT to flame which would also fix it not beign XDR compatible