Apple launches Apple Store app in India

The Apple Store app provides customers with the most personalized way to shop for Apple’s innovative lineup of products and services. Learn more >

You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Final Cut Pro 10.8.1 - problem with HDR videos since upgrading to MacOS Sequoia

Hi everyone, since I upgraded to Sequoia, HDR videos shot on an iPhone 14 Pro Max appear too dark in FCPX. Even when I open previous (finished) projects that looked fine under the previous version of MacOS, it does not show correctly.


After I treated my project as best as I could (but really not to my standards), if I export it to Compressor it then appears completely overexposed.


My screen is HDR and I enabled HDR in MacOS' setting. My Mac is a Min M2 Pro.


Anyone else encountered this problem ?

Mac mini, macOS 15.0

Posted on Sep 21, 2024 12:47 PM

Reply
Question marked as Top-ranking reply

Posted on Jan 10, 2025 7:42 AM

AlainBE, thank you, PF_Productions, IAmSkipperMark, Tom, Clint, and Luis *very* much for all your help on this. Re: why it's not sorted out: I don't work for Apple, but I have extensive experience in software testing, development, and escalation support, and I can explain how the system works.


  • Usually, nothing will get fixed solely by people talking about it on a forum. From a user standpoint, it feels like you've "reported" it, especially if details are given, but that will not normally result in Apple product support or engineering taking action. With some products, such as DaVinci Resolve, actual developers monitor the forums, but that is rare. There is also a valid argument it's not the best use of a developer's time.
  • Posting info on a forum is useful, and the more detail, the better. In this case, several users have collectively posted enough information to broadly understand the overall problem parameters. But took a while.
  • There have been numerous situations where users refuse to provide the requested info, such as an EtreCheck report or an error log. This can greatly delay problem resolution.
  • For complex hardware/software issues like this case, posting information on the Apple Product Feedback site is OK but will often not produce the desired results. That site allows just 800 characters max input (including spaces) and no ability to attach files, error logs, links, etc. It is simply not designed for that purpose.
  • There is an Apple Feedback Assistant app, but it requires a developer account and is generally oriented toward app developers, not end users, and not even sophisticated IT users.
  • The best approach for most users is to collect as much info as possible and then contact Apple Support. If the case is escalated, this can include ongoing two-way email discussions whereby you report new findings. I believe this particular case is in that state, and IAmSkippermark is driving this (thanks!)
  • If you are an experienced software developer or have done similar work, you can get an Apple Developer account and report the problem, including attachments, logs, and files needed to reproduce the issue. However, this can require lots of work if done properly. When bugs are filed this way and followed up by contacting product support, Apple has been very responsive. See attached for an example of one I filed.


However, there is a good argument that customers should not have to spend hours or days researching a bug. OTOH, those customers may spend hours or days discussing the bug on a forum, so time is being spent anyway. There is no simple solution for this, but it's important for everyone to understand what is required to get a bug fixed.


The fastest way to get a bug fixed is by achieving a specific (ideally portable) reproducible scenario and reporting it to Apple Support by opening a case. The scenario allows engineering to reproduce the problem under a debugger and quickly fix it. It also allows later testing of that scenario to ensure it stays fixed in a new software version.


But it can take lots of time and work to achieve that well-documented, portable replication scenario. When working on critical problems that I or others encountered, I've heard people say "You're doing Apple's work for them." That betrays a lack of understanding about how the system works and how serious some problems are. If not for these efforts, some problems would not be fixed in an expedited time frame, and the cost to some end users could be significant.


Errorlogs and crash logs are useful, but those by themselves may not enable fixing a bug. The underlying technical factors are too complex to explain in this post, but if anyone is interested, I can elaborate in another thread.


Incorporating even a single fix to a complex product requires a full battery of regression tests, stress tests, functional tests, performance tests, localization tests, and security tests, individually repeated on a complex matrix of platforms and configurations. If the fix involves interactions between FCP and MacOS code, it might require a MacOS update, and those have their own schedule. The fastest I've seen Apple implement an FCP fix was about three weeks from the initial report, and that was a highly urgent matter where the release contained only that one fix.

97 replies
Question marked as Top-ranking reply

Jan 10, 2025 7:42 AM in response to AlainBE

AlainBE, thank you, PF_Productions, IAmSkipperMark, Tom, Clint, and Luis *very* much for all your help on this. Re: why it's not sorted out: I don't work for Apple, but I have extensive experience in software testing, development, and escalation support, and I can explain how the system works.


  • Usually, nothing will get fixed solely by people talking about it on a forum. From a user standpoint, it feels like you've "reported" it, especially if details are given, but that will not normally result in Apple product support or engineering taking action. With some products, such as DaVinci Resolve, actual developers monitor the forums, but that is rare. There is also a valid argument it's not the best use of a developer's time.
  • Posting info on a forum is useful, and the more detail, the better. In this case, several users have collectively posted enough information to broadly understand the overall problem parameters. But took a while.
  • There have been numerous situations where users refuse to provide the requested info, such as an EtreCheck report or an error log. This can greatly delay problem resolution.
  • For complex hardware/software issues like this case, posting information on the Apple Product Feedback site is OK but will often not produce the desired results. That site allows just 800 characters max input (including spaces) and no ability to attach files, error logs, links, etc. It is simply not designed for that purpose.
  • There is an Apple Feedback Assistant app, but it requires a developer account and is generally oriented toward app developers, not end users, and not even sophisticated IT users.
  • The best approach for most users is to collect as much info as possible and then contact Apple Support. If the case is escalated, this can include ongoing two-way email discussions whereby you report new findings. I believe this particular case is in that state, and IAmSkippermark is driving this (thanks!)
  • If you are an experienced software developer or have done similar work, you can get an Apple Developer account and report the problem, including attachments, logs, and files needed to reproduce the issue. However, this can require lots of work if done properly. When bugs are filed this way and followed up by contacting product support, Apple has been very responsive. See attached for an example of one I filed.


However, there is a good argument that customers should not have to spend hours or days researching a bug. OTOH, those customers may spend hours or days discussing the bug on a forum, so time is being spent anyway. There is no simple solution for this, but it's important for everyone to understand what is required to get a bug fixed.


The fastest way to get a bug fixed is by achieving a specific (ideally portable) reproducible scenario and reporting it to Apple Support by opening a case. The scenario allows engineering to reproduce the problem under a debugger and quickly fix it. It also allows later testing of that scenario to ensure it stays fixed in a new software version.


But it can take lots of time and work to achieve that well-documented, portable replication scenario. When working on critical problems that I or others encountered, I've heard people say "You're doing Apple's work for them." That betrays a lack of understanding about how the system works and how serious some problems are. If not for these efforts, some problems would not be fixed in an expedited time frame, and the cost to some end users could be significant.


Errorlogs and crash logs are useful, but those by themselves may not enable fixing a bug. The underlying technical factors are too complex to explain in this post, but if anyone is interested, I can elaborate in another thread.


Incorporating even a single fix to a complex product requires a full battery of regression tests, stress tests, functional tests, performance tests, localization tests, and security tests, individually repeated on a complex matrix of platforms and configurations. If the fix involves interactions between FCP and MacOS code, it might require a MacOS update, and those have their own schedule. The fastest I've seen Apple implement an FCP fix was about three weeks from the initial report, and that was a highly urgent matter where the release contained only that one fix.

Jan 8, 2025 5:58 PM in response to AlainBE

For everyone following this thread, I've been talking with Apple support since this issue first appeared. The case was escalated to engineering, who has requested many application and system logs, copies of the footage (videos) that aren't working and more.


Today I received an email from support, and it said "Engineering states that the issue seems to be isolated to the 3rd party displays."


That didn't really tell me anything because that's what I've told them all along. The issue happens on 3rd party displays connected via HDMI. It doesn't happen with the Apple Studio Display or the Apple Pro Display XDR connected via Thunderbolt. I can't confirm if it happens with non-Apple monitors connected via Thunderbolt because I don't have access to one.


I replied to the email and asked, "So does that mean that Final Cut Pro cannot be used with a third-party monitor?"


Hopefully, they'll get back to me in the next couple days with a response. When they do, I'll be sure to update everyone.

Nov 14, 2024 2:08 PM in response to IAmSkippermark

I don't do formal HDR work but I've done lots of HDR HLG tests in FCP using an Apple Studio monitor and LG 5k monitor, both connected via Thunderbolt to my M1 Ultra Mac Studio. I've also tested on my M1 Max MacBook Pro 16. I've also uploaded HDR tests to Youtube and Vimeo and tested streaming playback on the above machine.


In general it works OK but Safari support for Youtube HDR is sketchy. It works well on Vimeo and MacOS Firefox works better on Youtube for streaming HDR content.


With those exceptions, in general I haven't seen any problems on recent prior or current versions of MacOS and FCP. But I don't have any machines which connect to monitors via HDMI.


I think there are some limitations on HDMI cable and endpoint versions for full support of 4k/59.94 Rec.2020 HLG with Dolby Vision 8.4 (what FCP exports). I don't recall any of the above posts stating what resolution and frame rate were being used.


It would be a good test to try 1080p at 23.98, 25.0 or 29.97 and see if that works using Rec.2020 HLG with Dolby Vision 8.4. That lowers the bandwidth a lot, which brings the scenario inside more specs for cables and endpoints. If making that change works better, that tends to imply it's a cable or endpoint issue.


When using HDR output from an Apple computer to an external monitor, a key issue is what display profile is used. If the display profile is not configured for HDR or one of the new presets like XDR P3-1600 nits, it won't look right. The newer Apple monitors have presets and the older ones and non-Apple monitors normally use ICC profiles. Which one is in use is shown in System Settings>Displays.


On any Mac with either built-in monitors like XDR MacBook Pros or with external monitors, you can test HDR by going to Youtube and searching for "HDR channel" and trying to stream those with Safari and Firefox. If you right-click and select "Stats for Nerds" that should indicate 'Color HLG / bt2020.' If it does not, there is a problem independent of FCP.


iPhones 12 and later can record HDR using 10-bit Rec.2020 HLG Dolby Vision. That does not have to be ProRes. If you enable HDR recording on the iPhone, you can upload that directly to Youtube or play the local file on an HDR-capable Mac -- without editing. That is another way to test whether your computer playback system can handle local or streaming HDR playback. Only if that works on the given computer and monitor is there any need to pursue whether you can edit and grade that using FCP: Adjust HDR camera settings on iPhone - Apple Support


Nov 14, 2024 8:05 AM in response to jeong306

Correct - it is still unresolved. I've installed every MacOS Sequoia update when they were released and just installed FCP 11, and the issue still persists.


Editing to add that I've spoken with tech support multiple times about this, but they don't have any updates. Last update I received from support was mid-October saying they don't have any updates, and they'd get back to me once they hear something from engineering. It's been two months have passed since Sequoia was release and the problem first appeared, but there are still no updates.

Nov 15, 2024 7:59 AM in response to IAmSkippermark

@IAmSkippermark: I can now see the problem. I connected my M1 Max MacBook Pro to my HDR/HLG/Dolby-capable LG C8 TV, and it behaves as you described. Quicktime playback shows as HDR, but within the FCP viewer (if connected to the TV), it does not. That is using Sequoia 15.1 and FCP 10.8.1 or FCP 11.0. Unfortunately, I don't have any machines still running Sonoma to test.


MacOS Settings>Display shows "LG.TV" as the color profile, and the HDR option is enabled in the UI.


If I disconnect the HDMI cable from the TV, the FCP viewer displays HDR. That is using an iPhone Rec.2020 HLG Dolby Vision clip in a Wide Gamut library and a Rec.2020 HLG project, with auto color conform on. I tried all combinations of color conform in FCP settings and the Inspector and none of those worked.


So when the MacBook Pro detects the TV is connected via HDMI, it handshakes and this somehow restricts the FCP viewer from displaying HDR in the MacBook Pro XDR screen or the HDMI-connected TV. But it does not affect Quicktime Player display of HDR/HLG content on either MacBook display or the HDMI-connected TV. This implies it is not an HDMI cable issue (although I'm using 8k-rated HDMI cables).


My TV by itself can clearly decode and show HDR HLG content if my TV streams it via ethernet using the WebOS Youtube app from a Youtube HDR channel.


This is a complex issue because several things are happening "under the covers." The playback app (Quicktime or FCP) reads the NCLC tags (aka code points) in the file metadata, the app decides how to handle that, then MacOS ColorSync does a match based on the display device color profile.


Simultaneously there is MacOS EDR (Extended Dynamic Range) technology which modifies the video output IF the internal or external monitor is an Apple device capable of HDR. The purpose of EDR is (1) To squeeze out the best image on an Apple display and (2) To differentially control luminance of the viewer window vs the UI elements. This avoids excessively bright UI elements during HDR playback. There are some WWDC talks on this.


I will have to do further testing and possibly run FCP under XCode to see what is happening. This could take several days.

Nov 14, 2024 1:43 PM in response to PF_Productions

Oh, no. I don't have a contact at Apple. I just reached out to the support team through the Apple website support page located here:


Final Cut Pro - Official Apple Support


I think it would be good for others to contact them too so they know it's not just an isolated case. My guess is only a small percentage of users edit in HDR, so the issue we're experiencing probably doesn't come up very often.


I'd suggest contacting them through their official contact page I posed above (or search for Final Cut Pro Support) if you don't like to click unknown links. If you call, you'll probably end up at with the Mac support team (this always happens to me for some reason), and they'll transfer you to the FCP team.


The email I received was pretty generic and said, "Thanks for your patience. I’m still waiting to hear from our engineers about your case. As soon as I receive a response, I’ll email you to coordinate a good day and time to call."


I ended up calling support today to see if there was an update and let them know the issue still exists in FCP 11. The person I spoke with (different person than the person I spoke to before - they can't transfer you to a specific advisor) saw all the notes and said they updated them so the engineers know about FCP 11. They're just waiting on the engineering team to get get back to them with an update, which can take some time.


I've contacted Apple support a few times before, and they are actually very good about getting back to you once they know something, so if I get any updates, I will be sure to update it here.

Sep 22, 2024 8:08 AM in response to AlainBE

I have the feeling that


  • the clips are not displayed correctly in FCPX although they are displayed correctly in the quick viewer.
  • FPCX actually applied the corrections to a properly "exposed" clip but that the clip is not shown as it should. You then have to boost the luminosity so that it "appears" OK in FCPX, but then when you render the file, it is overexposed.


When I reopen an archived project that was appearing as it should be in FCPX before upgrading th Sequoia, it is now way too dark as well.

Sep 22, 2024 8:03 AM in response to AlainBE

This is a screen capture of my Mac, using Cmd Shift 5: on the left the clip in FCPX timeline and on the right the rendered file in QuickTime Player. They appear identical, but check the next photo...



And here is a photo of the screen at the same time taken with my iPhone


The rendered file is completely washed out.

Final Cut Pro 10.8.1 - problem with HDR videos since upgrading to MacOS Sequoia

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.