Apple XDR and the resolve Viewport

So a few things first to get out of the way

1) This has nothing to do with all that "quicktime gamma bug" nonsense.

2) I know its not a proper way to monitor for grading, this is just to match a reference monitor next to it as best as possible.


I took a spectrophotometer (iPro3) and a regular probe (i1Display) with light illusions Colorspace and measured the EOTF of a macbook pro 14" XDR display with different resolve and display settings to find out what I need to do to get proper gamma 2.4 output on the display, as in matching a reference display calibrated to rec709/Gamma 2.4 (I use pure power law 2.4 and not bt1886 because i am using OLEDs and the miniLED which do 0 NIT black so its the same as 2.4 anyhow and less complex).

I ran 48 lineary spaced full range patches from 0->255 in resolves viewer and recorded the resulting measured values from the display output and then plotted them against gamma 2.4, obvious to see any not-correct EOTFs.

First thing I tried, and I assumed this would work but sadly did not
--------------------
UMDCPFV*: OFF
Display Setting: XDR Rec709/bt1886 reference mode system gamma boost 1.22 (default)
Output Colorspace(makes no difference here beacause UMPFV is turned off): rec709(scene)
Resulting EOTF = 2.2
--------------------

So I thought, why? somehow there is something not adding up, UMDCPFV*: OFF should just do nothing and send pixels "as is" to whatever the display is, in this case 2.4 gamma, so I assume apple is acually using the inverse of the default XDR profile to transform it to the working space(linear/XYZ)? Not sure, but I was able to fix it by using a System gamma Boost of 1.09 instead of 1.22

Code: Select all

2.4/1.961 = 1.22

Code: Select all

2.4/2.2 = 1.09


this gives me a measured EOTF of 2.4
--------------------
UMDCPFV*: OFF
Display Setting: XDR Rec709/bt1886 reference mode system gamma boost 1.09 (custom
Output Colorspace: whatever
Resulting EOTF = 2.4
--------------------


Ok cool, so with this I would get correct viewing in resolve but nowhere else like quicktime.. but I would be able to run colormanaged workflows in resolve.

The other way, which is how FCPX does it, is to:

--------------------
UMDCPFV*: ON
Display Setting: XDR Rec709/bt1886 reference mode system gamma boost 1.22 (default)
Output Colorspace: rec709A
Resulting EOTF = 2.4
--------------------

This obviously would have issues with running colormanaged, especially when using external proper monitoring as setting the output colorspace to 2.4 would result in a EOTF of roughly 2.6 on the XDR.


So Long story short what we need is a XDR compatible mode, ideally one that triggers different reference modes from inside resolve.

This mode (in SDR) should always display the same as FCPX and Quicktime, so always "rec709A" as that ends up displaying correct rec709/2.4 without beign effected by my colormanagement settings, even for non XDR it would be nice to seperate viewer colorspace from output colorspace..







UMDCPFV = Use Mac Display Color Profiles for viewers

The legendary Dave Abrams, one of the best calibration engineers in LA, just posted this video showing how Calman can be used to calibrate the (controversial) Apple XDR display:

Before, most of us said it couldn’t be done, but if Dave says it’s good, it’s good.

Yea just this has nothing to do with calibration, its a thing between resolve and MacOS.

Calibrating it is great, but doesnt help if you arent getting the right values&Metadata from resolve to actually display stuff correctly.

What is this "gamma boost" for?
Is it related to fact that native display gamma is 2.2, so as you pointed to get 2.4 they apply 1.09 boots?

I assume BT.1886 ref mode should give you correct 2.4 gamma.
With such a preset in case of Resolve it should work with UMDCPFV on or off (assuming you chosen 2.4 gamma in Resolve setup). Rec.709A is a legacy crap gamma of 1.96, wich is not really a gamma for display.
I think ref modes translate gamma, but they clip gamut. If your video has other than 2.4 gamma this will be converted, but if gamut is not eg. Rec.709 then it will be displayed wrongly (so gamut needs 1:1 matching like in pro displays). Non-reference modes convert gamma and gamut. Idea is that regardless of your video you can watch it with same monitor settings- so Rec.709 video is properly displayed on Apple default P3 gamut with 2.2 gamma. This of course should be avoided for grading (you want 1:1 mapping with least possible processing).

On iPad Pro when ref modes are enabled it behaves slightly differently. It will always try to switch into mode which your video is tagged, so 1-1-1 tagging will trigger BT.1886 mode, but eg. P3 HDR tagged video will switch to corresponding mode. I think if you have 2 QT players open each can use different mode independently. You can't force particular mode by yourself.

interesting with the reference mode on the iPad. that seems to make more sense maybe.


So apple says that 1.961 gamma encoding is correct for rec709.. thats just what they do and think. (no judgement..)

So for dark viewing a 1.22 gamma boost is required... so for them the content really is 1.961 but the display (or rather the OOTF) is adding a boost of 1.22 gamma ich ends up beign 2.4 (1.961*1.22= 2.4)...

If the source really is 2.4 gamma with 1-1-1 tags - it would do this order of operations afaik.

1. convert source from 1.961/rec709 to linear/XYZ
2. Convert linear/XYZ to gamma 2.4/rec709
3. Add 1.22 gamma boost to negate the first "wrong" transform


The thing withe the 1.09 gamma boost is non standard, i came up with this as the mac is NOT showing 2.4 gamma on non-ColorSync apps (like resolve with it turned off) but its showing gamma 2.2...

I dont know why this is, but I can measure and the displays response is gamma 2.2 , I expected it also to be 2.4 because that what it SHOULD do in reference mode, but its.. not.

But this is because you use Rec.709-A which really shouldn't exist.
Try rendering clip from Resolve project set to 2.4 gamma and play that clip in QT X (with default Resolve tags of 1-2-1+ gamma=2.4). This should give you correct preview in BT.1886 mode ( I assume this is the case which you described).

It's not like Apple says Rec.709 correct gamma is 1.96. This value is a reverse of original gamma for a recording device specified in Rec.709 spec. At the time QT spec was created there was no standard value for display in Rec.709 spec, so Apple (and not only) quite often used reverse of Rec.709, which approximates to 1.96. This is not really Apple's fault. This value has about no meaning in today's reality. For quite a time industry used 2.2 and now 2.4 (or more precisely BT.1886).
Apple could change math behind 1-1-1 tag today, but this is not the best/correct approach. Real solution for industry is to introduce new tag for BT.1886 which was never done! It was simply "missed/forgotten", so now 1-1-1 can mean 1.96, 2.2 or 2.4 gamma You simply don't know which one was used, so you can't display file reliably. For QT you can you use 1-2-1+ gamma tag (as Resolve does now for 2.4 gamma) to precisely tag video, but this only works for MOV format and it's not well supported (Resolve+ Baselight+ Flame started supporting it now I think). As I said- real solution is new industry standard tag or BT.1886, which can be added to MOV, h264/5 etc. so we can finally properly recognised majority of todays grades.

For web sRGB could work as OSX color system properly recognises it (and also many PC apps use it by default) and it's specified in MOV/h264/5 etc private headers, but in this case services like YT/Vimeo come into play as they simply will re-tag your sRGB graded and tagged masters to 1-1-1 (without actually any video change), so you back to wrong tag again I've tired to convince Vimeo to preserve sRGB tag, but after 3 months it went no where.
It's a mess mainly due to one simple thing- lack of tag for BT.1886.

This has list of today's industry recognised tags (which is replicated in MOV spec and cover codecs like h264/5, VP9, AV1 etc.)
https://github.com/bbc/qtff-parameter-editor
Apple supports only some combinations of them (eg. 2.2 tag is not recognised by OSX colorsync).
At least PQ and HLG is there- imagine 1 or no tag for HDR- that would be real fun
We have quite a few possible standards now, so it's a must that each file is precisely tagged with correct metadata describing real nature of your video. Without tags there is simply no way to automatically display it correctly.

But this is because you use Rec.709-A which really shouldn't exist.
Try rendering clip from Resolve project set to 2.4 gamma and play that clip in QT X (with default Resolve tags of 1-2-1+ gamma=2.4). This should give you correct preview in BT.1886 mode ( I assume this is the case which you described).

It does not. Have you used a XDR display? they work compeltely different and the 1-2-1 gamma 2.4 quicktime "trick" that many tools like resolve and flame use - is not valid anymore with XDR displays they add a 1.22 gamma boost so the files still have to be tagged 1.961 ... 1.961 * 1.22 = 2.4

It's not like Apple says Rec.709 correct gamma is 1.96.

They do, thats the thing.. lets get into it.

Generally Apple uses 1.961 as the encoding transfer function of rec.709 video. This particular figure isn’t often discussed because it is mostly useful for linearizing the signal to provide color management in a linear domain.
Further Apple feels that the rec.709 workflow provides implicitly includes a 1.22 gamma ‘boost’ that provides the required simultaneous contrast correction to make the video signal have the correct tonality (contrast) when viewed in the dim 16 lux reference viewing environment.

Next you might ask why is Apple know these things does it choose to render to the Mac as 1.961 without adding boost (thus causing a different appearance than rec.709 to a reference display)?

In answer to that a) Apple does produce the reference response when rendering rec.709 to Pro Display XDR in bt.1886 rec.709 preset, also b) Apple also render reference response to a 2.4 gamma display when attached via HDMI

This leaves us with rec.709 as rendered to the Mac’s internal display, or external display connected via DisplayPort. In this case we assume the Mac is being used in a bright surround environment (one where the display’s reference white brightness is approximately equivalent to the brightness of the environmental surround as is the case with autobrightness or manual brightness use in office and brighter environments). There is no boost required for viewing the natively bright surround rec.709 content (it is bright surround which is why it requires the 1.22 boost for dim surround viewing. so Apple is providing the correct response for this environment. Further use of a reference display response in the bright environment is actually wrong.

So apple definetely deliberately uses 1.961 its not a bug not a fault, its a feature with meaning behind it.


I strongly believe that 1-2-1 / 2.4 NCLC/Gamma tags are not a thing anyone should do and are a workaround, there is a reason FCPX does not do this..

We dont have another standard for SDR video other than Rec709 so thats what we have to deal with, nobody ever specified sRGB for web-video and its that just how it is.

MY problem is not even related to all of this, my problem is resolves viewer not behaving correctly when used in Bt1886 Reference mode on a XDR display.

here are the measured responses from resolved viewer with "Mac display blah" turned OFF in bt1886/HDTV reference mode :
https://imgur.com/a/4QayCSy
its Gamma 2.6

here is it with mac display blah turned ON and rec709A used as "output colorspace" (without any colormanagement)
https://imgur.com/a/3U9g4QT
its perfect power-law gamma 2.4

same holds true for 1-1-1 exported quicktimes... so yea it works and no 1-2-1 should NEVER be used.

Apple never suggested to use 1-2-1 + gamma as they always ask to use 1-1-1, hence their reference modes by default add extra boost to compensate original math based on 1.96. This is not good at all. This is very bad and crazy confusing.
1.96/Rec.709-A is useless as it's not any standard! Apple with ref modes keeps patching old behaviour - bad, very bad. Good thing is that you can disable extra gamma boost and hopefully this way get proper 2.4 ref mode.

Can you tell me what you get with BT.1886 ref mode when gamma boost is simply turned off and Resolve is set to Rec.709+2.4 gamma?

Also what you get when 2.4 gamma graded file is tagged as 1-2-1 (+2.4 gamma, so Resolve default render) and then same file 1-1-1 flagged (so Apple way) in case of BT.1886 ref mode without any gamma boost?

same holds true for 1-1-1 exported quicktimes... so yea it works and no 1-2-1 should NEVER be used.

Just to be sure- are we talking Rec.709-A or 2.4 graded files/Resolve project as this is key info here?

Btw... great work as you are the first person who actually measured things instead of repeating myths
This way we can create accurate info and understand Apple logic behind ref modes (I think I already understand what they've done and I don't like it).

So apple definetely deliberately uses 1.961 its not a bug not a fault, its a feature with meaning behind it.

I strongly believe that 1-2-1 / 2.4 NCLC/Gamma tags are not a thing anyone should do and are a workaround, there is a reason FCPX does not do this..

I see it as patching legacy standard, instead of introducing correct/today's one.
FCPX doesn't use it as Apple stays firmly on using 1-1-1 tag and (maybe) because FXPC is using 1.96 math behind Rec.709 projects where whole industry relies on proper 2.4 (or 2.2) gamma! As said many times- you can't have scenario where 1-1-1 tag is used for files graded to 3 different gammas! Apple assumes you used 1.96 and mandates use of 1-1-1 tag, where whole industry uses 2.4 (or 2.2) still flagging with same 1-1-1 tag (as 1.96 is not a standard!).

1.96 is a bad value, value which should never been used for a display, but it was used due to lack of a 'proper' one. Studios "invented" unofficial one as 2.2 (may be wrong here) and later we actually did get proper standard (BT.1886) based on 2.4. Problem is that none of those two values (2.2 nor 2.4) was properly introduced into industry, so Apple also never added them and all stayed with this "bad" 1.96.
As of today BT.1886 still doesn't have any reflection in standards, eg. list of possible values in codecs headers.
Funny that with introduction of HDR industry did add new tags and you can properly flag PQ or HLG based file. This missing tag for BT.1886 (+ also indirectly lack of defined gamma for display in original Rec.709 spec) is the whole reason for all this mess. Now, it got even worse as Apple is still patching this old behaviour through introduction of "gamma boost" in ref modes. At least this is how I see it.

They arent patching stuff, they know exactly why they do it , its on purpose.

The 2.4 Gamma display is - by spec - only to be used on dim surround viewing not for Daylight so the actual correct response is 1.961...

Thats just what it is... the idea is that it works as a surround compensation.

Do I think this works well? hell no. not a believer just trying to figure out what apple is thinking because they dont publicly Document ANYTHING.

There are two ways I derive the 1.961 value:

First, back in the day a rec.709 CRT’s was measured to have a little over a 2.4 gamma pure-power response. The 2.4 gamma figure is now codified in bt.1886. Divide this value by the expected 1.22 boost and you get something close.

Next take the piecewise-linear followed by 2.2 gamma curve recommended encoding. Ever wonder what pure-power function they were approximating? Try solving for pure-power function with the area under the piecewise curve. You get the 1.961 value.

Charles Poynton writes that the encoding is a square root, e.g. gamma 2. In conversation with Charles he agrees this is the same figure apple is referring to.

so take that as you want but you could argue that apple are the only ones doing it right, or whatever... its a different discussion


I might be able to check what 1-2-1 does in reference mode but I dont really want to, its a old depreceated workaround that didnt even work perfectly on older macs

2.4-> Linear -> 2.2(mac display) would still introduce a slight shift and not give you a reference response, so i never liked the 1-2-1 workaround (2.4 gamma tag implied when I say 1-2-1) as its not compatible with anything and shouldnt be.

I dont think we need a bt1886 quicktime tag, I used to think we do, but we really do not.

what we are missing is a standard that UNIFIES still images and video .. Maybe we can finally get there with HDR but thanks to the fancy BBC we now have HLG and PQ, thanks for nothing -.-

Just to be sure- are we talking Rec.709-A or 2.4 graded files/Resolve project as this is key info here?

Btw... great work as you are the first person who actually measured things instead of repeating myths
This way we can create accurate info and understand Apple logic behind ref modes (I think I already understand what they've done and I don't like it).

[/quote]

Thanks I am just looking at it analytically measuring the difference between the values i put in and what comes out of the display... thats the only way to stay sane when dealing with colorsync.

I am not talking about colormanagement or converting values I am ONLY using rec709A to trigger the right metadata from the resolve viewer. I dont have "rec709A graded files" or anything , the idea is not to grade to a rec709A target or some other BS of whats floating around the internet to "fix the gamma bug"

All i am doing is displaying a series of patches with known RGB values and measuring/plotting the response from the display or rather the whole system as we cant controll them individually like we could with a waveformer sitting between resolve and a reference monitor. So i have to view this as a blackbox with some dials.

isnt the only diff between rec709(scene) and rec709A the age old question wether to use a linear portion in the blacks or not? idk if there will ever be consensous about which one is the correct rec709

There are two ways I derive the 1.961 value:

This is coming from original Rec.709 spec.

Rec. 709 OETF is linear in the bottom part and then a power function with a gamma 0.45 (about 1/2.2) for the rest of the range. The overall OETF approximate to a pure power function with a gamma 0.50-0.53 (about 1/1.9 - 1/2.0). Using any pure gamma as OETF is impossible, because compression into nonlinear values will remove a lot immediately near black shadows. Thus linear segment was invented and a gamma of 0.45 has been used for the power segment. Old CRTs had a EOTF of 2.35 pure gamma[15] and thus the corresponding correction of 709 OETF to get EOTF linear image (if 1.2 end-to-end gamma is assumed) was a pure gamma of 1.2 / 2.35 = 0.51 = 1/1.9608. It was used in such way by Apple until Display P3 devices came into existence.

I am not talking about colormanagement or converting values I am ONLY using rec709A to trigger the right metadata from the resolve viewer. I dont have "rec709A graded files" or anything , the idea is not to grade to a rec709A target or some other BS of whats floating around the internet to "fix the gamma bug"

Set Resolve to 2.4 as this is what you want to use. Does it give 2.4 response for BT.18886 ref mode?
Not only what you see needs to be 2.4 based but actual file has to be 2.4 based (and if you use Rec.709-A then it won't be), so on any ref screen set to 2.4 you get correct preview.

Before ref modes you either had to grade to 1.96 (Rec.709-A) as this is what Apple color sync uses for 1-1-1 tag when converting to display profile or you had to use 1-2-1 + 'actually gamma used for grading' tag. Both ways gave you correct preview on OSX, but only 2nd way gave you correct file which works on every device based on industry used 2.2 or 2.4 values.

Based on what you say when I take 2.4 graded file and display it with ref mode I won't get correct preview at all, which negates whole idea of ref modes

Set Resolve to 2.4 as this is what you want to use. Does it give 2.4 response for BT.18886 ref mode?
Not only what you see needs to be 2.4 based but actual file has to be 2.4 based, so on ref screen set to 2.4 you get correct preview.

Changing resolve output colorspaces in unmanaged mode does not change the image at all so it doesnt matter.
it does NOT give a 2.4 response in ref mode, not at all. I dont view a "file" i run calibration patches from colorspace, there is literally no media that has a "gamma" the patches are just linearly even spaced values between 0 and 255,. if the system had a linear response and wasnt gamma based i would get a linear plot.

This is how you calibrate and profile displays, i really dont understand what a "file colorspace" has to do with anything here, it really doesnt.

I am also always cross refferencing a actually proper 2.4 gamma reference monitor that is next to the ProDisplay XDR visually.

There are two ways I derive the 1.961 value:

This is coming from original Rec.709 spec.

Rec. 709 OETF is linear in the bottom part and then a power function with a gamma 0.45 (about 1/2.2) for the rest of the range. The overall OETF approximate to a pure power function with a gamma 0.50-0.53 (about 1/1.9 - 1/2.0). Using any pure gamma as OETF is impossible, because compression into nonlinear values will remove a lot immediately near black shadows. Thus linear segment was invented and a gamma of 0.45 has been used for the power segment. Old CRTs had a EOTF of 2.35 pure gamma[15] and thus the corresponding correction of 709 OETF to get EOTF linear image (if 1.2 end-to-end gamma is assumed) was a pure gamma of 1.2 / 2.35 = 0.51 = 1/1.9608. It was used in such way by Apple until Display P3 devices came into existence.

Ok, fine i am happy if apple is wrong, but then it doesnt matter, i just want to have a button in resolve that makes my XDR monitor show the right thing

Set Resolve to 2.4 as this is what you want to use. Does it give 2.4 response for BT.18886 ref mode?
Not only what you see needs to be 2.4 based but actual file has to be 2.4 based, so on ref screen set to 2.4 you get correct preview.

Changing resolve output colorspaces in unmanaged mode does not change the image at all so it doesnt matter.
it does NOT give a 2.4 response in ref mode, not at all. I dont view a "file" i run calibration patches from colorspace, there is literally no media that has a "gamma" the patches are just linearly even spaced values between 0 and 255,. if the system had a linear response and wasnt gamma based i would get a linear plot.

This is how you calibrate and profile displays, i really dont understand what a "file colorspace" has to do with anything here, it really doesnt.

I am also always cross refferencing a actually proper 2.4 gamma reference monitor that is next to the ProDisplay XDR visually.

Not sure I understand. You want to have display with gamma response of 2.4, so anything (including Resolve preview) will be based on it? If you create own ref mode with pure gamma of 2.4 (no boost) it has to work regardless if Resolve will be set to use profile or not.

[Peter Chamberlain]

Are you using the “HDR Video (P3-ST 2084)” preset in display settings?

I understand that the default “Apple XDR display” one uses the old Rec.709-A assumption and that the HDR one works for both HDR and SDR outputs.

Are you using the “HDR Video (P3-ST 2084)” preset in display settings?

I understand that the default “Apple XDR display” one uses the old Rec.709-A assumption and that the HDR one works for both HDR and SDR outputs.

No, I am using the HDTV VIDEO - BT709- BT1886 XDR reference mode.

https://imgur.com/a/D4f8oLw



very interesting with the HDR reference mode as Autodesk told me something similar, whats the right resolve settings to make that work then? Because that preset uses gamma 2.2 for SDR and stuff, which probably might actually work for SDR viewing with "Mac viewer..." turnd off. which would be VERY confusing why i would have to use a HDR reference mode for SDR viewing and not the SDR reference mode

https://imgur.com/a/WAA4kHZ

Going to measure this tomorrow, just on my laptop however looking at the flanders perceptual matching chart it doesnt seem to work. espeically when I turn of "use mac display profile" I get P3 values displayed so its completely out of whack.

Not sure I understand. You want to have display with gamma response of 2.4, so anything (including Resolve preview) will be based on it? If you create own ref mode with pure gamma of 2.4 (no boost) it has to work regardless if Resolve will be set to use profile or not.

Doesnt work because you still have the conversion from X to linear to Reference mode in colorsync. this is not how refence modes work sadly. You would assume it would work like win/linux connected to a proper 2.4 gamma display, but its not what it does! Colorsync is still active!

I assumed when reading about reference modes that this is how it works.. but thats not it.

also considering that the Apple Studio display DOES have SDR reference modes but no HDR reference modes.

HDR reference modes for SDR vieweing doesnt seem to be the answer.

Those ref modes are definitely strange and not necessarily what you would expect

I also posted this on Liftgammagain but thought it would be a good idea to share here as well as I can only image onthers facing this issue.

Current settings to get the best visual match between Resolve viewer, Iina, QT player and iPhone on an M2 max XDR display and the Flanders CM250

Mac display profile(s):
1. HDR Video (P3-ST 2084) (got that from here, currently using this profile)
or
2. HDTV Video (BT.709-BT.1886) (Apply System Gamma Boost turned OFF)

Resolve settings:
Preferences -> System -> General
1. Use 10-bit precision in viewers if available CHECKED
2. Use Mac display color profile vor viewers CHECKED

Resolve Project settings:
Color management
1. Timeline color space: Rec.709-A
2. Output color space: Same as Timeline

Resolve Export setting for ProRes:
Advanced settings
Gamma Tag: Same as Project

For my own reference, but thought it would be good to have it here for others to discover

Strangely the default HDTV Video (BT.709-BT.1886) display profile seems 100% useless because of the gamma boost setting.

I recently got notes on a grade from someone who viewed a prores (done properly I might add on my CM250) in QT on their MBP with XDR display in default display setting (which I had no clue about). Safe to say that caused some head scratching until we sat down together and I saw what they had been looking at..

It sounds strange as you should need boost to get final 2.4 gamma (unless XDR monitor does "boost" internally).

I also posted this on Liftgammagain but thought it would be a good idea to share here as well as I can only image onthers facing this issue.

Current settings to get the best visual match between Resolve viewer, Iina, QT player and iPhone on an M2 max XDR display and the Flanders CM250

Call me crazy: I just accept that all of these are never going to match, and I only believe the calibrated display on top. Everything else has too many potential points of failure, an example of Chaos Theory as it applies to color and imaging. There are very good reasons why all those different displays will never look identical. A big part of the reason is: they're all cheap and crappy and made to a low standard.

I think it is possible to play back an image on a calibrated display and get it close (but not exact) on a recent iPhone or iPad using Apple's Rec709/BT1886 defaults:



It's not perfect, but it is acceptable for our purposes. As has been discussed a thousand times before in the last 10 years, every display can potentially change the image, and there's no real way to predict how it will change (or control the change). We tell our clients in our contract, "we only guarantee image quality on displays under our direct control," which is true. It's good in the room; how it behaves in the outside world will be due to factors we can't predict. Sound has the same problem.

Ok Marc, You're crazy

Sure, too many variables in displays these days, you only ever see your "real" work on the display you graded on, everything else will be skewed a little or a lot one way or the other.

As I mentioned, these MacBook Pro and Resolve settings are what gets me a close visual match.
I have done grades on my MBP XDR display, continued on my CM250 and sanity checked on iPad and iPhones, and have it signed off. This has also been for prime time broadcast, so is certainly "good enough".

*If* your are grading on or sending files for approval in a newer Mac workflow, this would be the recommended way to go I believe.

And I should naturally emphasise that I do not get 100% match between devices, but certainly not any major discrepancies (as was the case before I took some time to dive into the settings)

You will never get 100% match on 2 different brands, even on 30K displays (this is why many studios will never have 2 grading screens in 1 room).
It doesn't matter though as each of those screens is treated as reference.

For Apple wording 1.22 boost on top of 1.96 (this is what files are encoded with in Resolve of Rec.709 preset) is around 2.4 and 1.09 boost gives 2.2 equivalent preview gamma.

Some of the recommendations in this thread are in contrast to the following article:

https://www.thepostprocess.com/2020/07/17/color-on-mac-displays-from-davinci-resolve-to-the-internet-with-quicktime-tags/

FWIW the article talks about the destination (web or theatre) as being an important consideration and also whether the web content will be played back on macOS or Windows (and even which decode software is used be it QuickTime, VLC, YouTube, Vimeo, etc...).

So for web, the author suggests grading with output set to Rec709/gamma2.2 (using BT.1886 reference mode on the XDR display with gamma set to 2.2) but tagging the output file as Rec709/Rec709-A.

The intent in this article is to get a file that plays back on macOS and Windows with as close an agreement as possible between all the platforms. The author acknowledges that it is impossible to get complete agreement which is why this is a 'best possible' and not absolute.

This thread focuses on trying to get the Apple display looking as close to a reference monitor as possible. Sounds like if you combine these two ideas the reference monitor should be set to gamma 2.2 if you are grading for web delivery.

I'm just rambling a bit as I've struggled with this as well. In the end I used the advice in the linked article but set my BT.1886 reference mode to gamma 2.2 rather than the default of gamma 2.4) and my external monitor is calibrated to gamma 2.2. Again, this is only for web delivery.

If I upload my output to YouTube (tagged as 1-1-1) the playback on my iPad Pro looks very close to what I was seeing on my grading monitor and that's my goal. I realize that the goal as stated in this thread is slightly different and the OP raising some very interesting points that make me question objective reality, lol.

For 2.2 preview create custom ref mode based on BT.1886 and change boost value to 1.09.

For 2.2 preview create custom ref mode based on BT.1886 and change boost value to 1.09.

I read that here - I'm not sure why I can't just set the gamma to 2.2 as pure power fn when editing the custom ref mode. I'll give it a try with the boost value and see if that more closely matches my calibrated monitor. Thx.

Add - thinking about this a bit more, I wonder when the gamma boost is used - is that only for color sync - so when a video has a 1-1-1 tagging of gamma 1.96 does the boost value kick in to take the image to gamma 2.2? What happens when the video is already tagged at gamma 2.2? You know, I'm going to have to go through the above thread again to see if I can answer my own question.

Problem is that your file has to be 1.96 gamma encoded and have 1-1-1 tag. Then ref BT.1886 mode make sense at least by theory. It seems to work differently when you use pure curve gamma.
In such a case I would say file needs to be 2.2 encoded (and flagged), which is not a standard practice.
Files should be 1.96 gamma encoded and then your viewing device applies on top "correction" (for Apple boost) to desired final viewing gamma- 2.2, 2.4 etc.

What I've found is that I must set my output color space and gamma to match my monitor and my delivery (my intent is to grade in 2.2 and deliver an output via CST to Rec709 gamma 2.2. With the viewers set in Resolve to use the Apple display profile (and the profile set to BT.1886 customized to gamma 2.2 I get an image in Resolve that looks identical to the feed to my external monitor which is also calibrated to gamma 2.2. So I'm good with this setup. Setting the custom BT.1886 to gamma 2.2 seemed to do the job. I tried setting the boost to 1.09 but didn't see any difference in the output but that may be because I'm using a gamma of 2.2 in my output from Resolve (output color space / gamma 2.2).

The only time I set tags to Rec709/Rec709-A is in the output file (does not encode as Rec709-A, this is just a trick tagging as explained in the post process article I linked to earlier.

So now I get agreement between my MacBook XDR display in Resolve, my external monitor and when I output my test video to YouTube and view it on my iPad Pro, it looks close enough be satisfy my needs.

Testing a bit more with the boost of 1.09 I found that the output file tagged 1-1-1 actually has a better correlation in the darkest regions with the Resolve viewer and my external viewer (so as viewed in QuickTime) so this is good to know.

For those reference BT.1886 modes file has to be encoded with 1.96 gamma (Resolve Rec.709+2.2 gamma presets doesn't export 1.96, so this is a special case). Rec.709 Scene or 2.4 will export 1.96 encoded file, so then depending on your boost in ref mode setting you can have 2.4 or 2.2 final viewing. Those are not pure gammas, so this may be a reason why it matches your ref screen better than pure 2.2 export+ 2.2 preview curve.

If 1.96 encoded file does give same preview as ref screen through ref mode with correct boost then this is actually good news Apple ref modes work very different than I thought, but at least now it's known what to expect.