An other, related issue with CGSetDisplayTransferByTable() - this is probably not the best place to note this, but since macOS Tahoe there is an inconsistency in how the API works. The 26.4 RC is also affected.
Before macOS Tahoe CGSetDisplayTransferByTable() redefined the color table of the SDR range and clipped the HDR range (much like custom color profiles in macOS usually do the same). In macOS Tahoe it does the same thing for most displays – except for the built-in XDR displays, when auto brightness is enabled and the display is in EDR mode (meaning: there is some HDR content on screen).
When this happens (XDR + auto brightness + EDR mode), the contents of the CGSetDisplayTransferByTable is being used to multiply the entire EDR (SDR+HDR) gamma range instead of overwriting the SDR range and clipping the HDR range. This might be a blessing in disguise for some apps (that use this feature for color adjustments or brightness upscaling like BetterDisplay - as this allows avoiding HDR clipping when a custom color table is being used for image adjustments), but since the behavior is inconsistent (with auto brightness disabled the very same function does affect only the SDR range and clips the enitre HDR range at 1.0 - peak SDR - luminance level as it used to do pre-Tahoe), this is probably just a bug, not a feature. Additionally, when a custom color table is applied to a built-in XDR display while in EDR mode is active, when the user turns of auto-brightness, the color table usually ends up in an inconsistent state (and the screen looks permanently bad until the user changes presets or do something similarly drastic) even after the app using CGSetDisplayTransferByTable() is terminated.
I do not have an FB filed for this one as honestly I saw very low chance of it reaching the appropriate engineers (being such an edge-case) - just wanted this to be out in case somebody in the team working on these things can do something about it. :)
