iPhone vs FCP: How to get the same HDR result?

A short white paper describing SDR and Wide-Gamut HDR and how FCP handles them. https://www.apple.com/final-cut-pro/docs/HDR_WideColor.pdf

HDR and SDR video will look different, as they have different color spaces, to start with. Yes, FCP compensates for SDR color space when you place an HDR clip into an SDR Project. Otherwise your HDR video would be super blown out and useless. Color grading is the only solution.

Quicktime Player local playback of an iPhone 15 Pro ProRes 422 Rec.2020 HLG file looks the same as the exported FCP file using the Format: Computer, HEVC 10-bit HLG Dolby Vision preset on my M1 Ultra Mac Studio, Apple Studio monitor, and using the default MacOS System Settings>Display>Preset>P3-600 nit preset.

I was using FCP 10.8.1 and Sequoia 15.01, however I previously tried it on Sonoma 14.7 and that also worked.

I left the FCP Settings>General>HDR>Automatic Color Conform enabled, also the video Inspector>Color Conform>Type: Automatic enabled. This was using a Wide Gamut library and the project was "Wide Gamut HDR - Rec. 2020 HLG."

I also tested it on an LG 5k Thunderbolt monitor using a Rec.709-BT.1886 gamma 2.4 display profile, and it looked OK there also.

I didn't have handy an iPhone 15 Pro HEVC Rec.2020 HLG Dolby Vision file, but I'll try to test that today sometime.

In general I suggest you leave the FCP auto color conform options enabled. If you are not on FCP 10.8.x, that could be an issue. The monitor type and MacOS color profile is very important because ColorSync reads the NCLC tags (aka code points) from the Quicktime header to understand how to match that with the display. It needs the correct monitor color profile to achieve that.

You can check the code points are as expected in the files by playing in Quicktime, doing CMD+I and expanding Video Details. The code points for Rec.2020 HLG should be 9-18-9.

Edit/add: Please use MacOS System Settings>Displays and examine what color profile is used for EACH of your monitors. Post those results here. Note there are two different systems: The Apple XDR monitor, Studio Monitor and newer MacBook Pros with Liquid Retina or XDR displays have the "preset" system, whereas other monitors and older Macs have the ICC "color profile" system.

I tested iPhone 15 Pro HEVC Dolby Vision, Version 1.0, Profile 8.4. Quicktime Player CMD+I showed:

Color Primaries: ITU-R BT.2020

Transfer Function: ITU-R BT.2100 (HLG)

YCbCr Matrix: ITU-R BT.2020

Code Points: (9-18-9)

I then imported to FCP and exported using Format: Computer, Video Codec: HEVC (10-bit HLG Dolby Vision), Resolution 4k, Color Space: Wide Gamut - Rec. 2020 HLG. I tested it on my Apple Studio monitor using the P3-600 nit preset, on my LG 5k monitor using a Rec.709 ICC profile, and on my M1 Max MacBook Pro using the XDR P3-1600 nit preset (which is essentially HDR or near HDR). It worked OK on all of them, but of course the SDR monitor wasn't quite as bright or vivid.

There is an issue on the newer Apple monitors (inc'l XDR Pro, Apple Studio, MacBook Pros with XDR screens) whereby if MacOS>Settings>Display>Preset is set to anything besides the default preset or (on MacBooks) the HDR Video (P3-ST 2084) preset, Apple-produced HLG material will not display correctly. It is typically very bright and blown out, as if playback cannot "down shift" the HLG material to an SDR display profile.

This also happens if you use the ColorSync or Calibrite utilities to load an SDR ICC profile for those monitors. Those monitors can operate in "preset mode" or ICC mode, and it happens with both modes on SDR presets or profiles. It does not happen if using the same ICC profile on an SDR monitor such as the LG 5k.

Since the LG 5k thunderbolt monitor is internally very similar to the Apple Studio monitor, that is interesting.

However that is a different problem than you are seeing. I only mention this for future reference.

For your case we need to know the hardware specifics of your HDR and SDR monitors and which MacOS>Settings>Display preset or ICC profile are in use on each one.

We also need to know the MacOS version, FCP version and iOS version on the iPhone 13 Pro.

Robin, I downloaded and examined your files on multiple Macs, using both SDR and HDR monitors. I generally don't see the same difference you posted above. On some machines and monitors, I can see a small gamma difference when playing your iPhone HLG video and the exported FCP HLG version back to back using "Quick Look." But it's quite small.

I also see that small difference when playing those two versions on my M1 Max MacBook Pro 16 using the default P3-1600 nit profile. Likewise, I see the small difference when playing them on an SDR monitor using a Rec.709 display profile.

Please import to FCP the file you exported, put that and the original iPhone HLG file on the same HLG timeline in the Wide Gamut library, and play them in FCP. Is there any difference then? You can also create a Standard Gamut library, create a Rec.709 timeline, import and play them there. Make sure you have Automatic Color Conform enabled in settings and at the clip level in the video inspector.

On my machines, I don't see the slightest difference in that case. Unlike Quicktime Player, FCP does not read and interpret the NCLC code points from the video metadata on ingest or playback. If there is a difference between the clips during Quicktime playback but not during FCP playback, this implies an issue with ColorSync.

ColorSync is the MacOS subsystem that color matches the clip based on file metadata to the display device's ICC color profile. In the case of new Apple displays with the reference profile system, what data ColorSync uses for the display match is undocumented, but the concept is similar.

You can also do a similar test by playing both clips using VLC or DaVinci Resolve, which are not color-managed and don't use ColorSync.

The MediaInfo utility shows some additional metadata in the iPhone clip. This might somehow be triggering the (apparently incorrect) ColorSync behavior.

I think your only immediate workaround is to use VLC or some other player, not Quicktime. This is a complicated issue that needs deeper examination.

Please let me know the results of your tests.

Robin, I spent about 2 hr on the phone with a video engineer I sometimes work with. We examined the files using QCTools Datascope. The video data is encoded as Y'CbCr, or gamma-corrected luminance as Y, Cb is blue component difference from luman and Cr is red component difference from luma.

Comparing the two files showed the underlying video data is essentially identical. That means the differences you see are a playback artifact. VLC or playing the files within FCP does not show the difference, so that implies it may be a ColorSync or metadata interpretation issue. We tested it on various Macs and MacOS versions from Monterey to Sequoia. The difference is seen in all of them to some degree if played in Quicktime. There is nothing you did to cause this, and the only immediate workaround is to use VLC.

There are also varying differences in whether the files are played on the new-type Apple monitors with reference mode presets or a monitor with normal ICC color profiles. In general the difference is more obvious on the new monitors. This isn't unexpected since the reference preset logic is apparently different from the previous ICC profile method. Whether it should display as different, I am examining.

There is a new HDR component in MacOS called Extended Dynamic Range which attempts to optimize HDR material. I think it is unique to the new monitor types but I'm not sure. There are some WWDC talks on that. Since the behavior seems more obvious on the new "refernce mode" Apple monitors, it might involve EDR to some degree. However it also manifests on much older machines and monitors.

I'll post any updated results here but this is a very complex issue that will require some time to understand.

Yes forsure keep it 100