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

Jan 10, 2025 10:25 AM in response to AlainBE

Replaying on this board is so confusing as the order is all over the palce. I'd like to say to Iamskipermark who just said today Apple claims its a 3rd party issue with Sequoia still that it makes no sense that its a monitor issue when everything else out of the macbook pro WORKS ON THE SAME MONITOR IN HDR! It's just the ouptut of FCP that no longer does. Really makes me scratch my head at that response from them???

Jan 10, 2025 11:01 AM in response to Luis Sequeira1

Thank you everyone for your replies/feedback/suggestions and explanations !


I confirm that all HDR signals transferred to my LG monitor connected via Thunderbolt 4 are showing properly, except for those coming from FCPX/FCPXI.


It is obviously a Sequoia/FCP issue. I hope it gets solved quickly.


A friend of mine seemed to have a similar problem with Adobe Premiere after upgrading to Sequoia. He didn't go into details but seemed to think it came from the AI items introduced in the latest version of the software...

Jan 11, 2025 5:30 AM in response to AlainBE

AlainBE wrote:
I am the one who started this post months ago

In the mean time, I have reverted to shoot in SDR.


Obviously this is a serious problem that needs to be sorted out but surely the simplest solution would be to revert to Sonoma until it gets sorted. Is there anything specific to Sequoia that you really need? There is always a danger in updating to a new OS early, particularly for 3rd party hardware. I always seem to have a battle with my Epson printer every time I upgrade macOS.


Also I don’t know what camera you are using but if you shoot in log or raw you should be able to process in HDR anyway, now or in the future. You shouldn’t need to shoot in SDR.


Jan 11, 2025 6:24 AM in response to Clint Gryke

Good point, Clint. All content shot in 10-bit 4:2:2 (or above): C-Log3, S-Log3, V-Log, D-Log, etc is inherently HDR from a dynamic range and color gamut standpoint. If edited in an SDR library using an SDR project, the material's latent HDR capability is unused. But it is always present.


E.g, I usually grade my FX6's 10-bit 4:2:2 XAVC-I S-Log3/S-Gamut3.cine material as SDR, but it contains 12.8 stops dynamic range and the S-Gamut3.cine color space is roughly similar to Rec.2020. I could take any of that material shot over the past several years and regrade that in an HDR library and Rec.2020 HLG project as true HDR.


When importing a ProRes RAW clip, FCP notifies you that it's HDR and asks what library type you want. But that's just a convention. In reality, it's no more HDR than S-Log3 material from the same camera. They both have HDR dynamic range and color gamuts.


In fact it's often better to *not* shoot in a specific in-camera HDR format such as HLG. That was not originally designed as a recording format to be later edited. That said, an iPhone does a pretty good job of recording Rec.2020 HLG internally, but my iPhone preference would be ProRes Log, then editing that in an HDR library/project and exporting as Rec.2020 10-bit HLG with Dolby Vision 8.4. FCP has a preset for that.


But none of that matters if you can't *see* the HDR on an HDR monitor to grade it. That is what this bug affects. Whether the camera material is S-Log3 or ProRes RAW, as of Sequoia, that content cannot be viewed properly in FCP if connected to a non-Apple HDR monitor. Even professional monitors like the $11,000 Flanders Scientific XMP310 are affected. It's hard to believe this was missed in testing.


As you said, it shouldn't be necessary to shoot in an SDR format such as Rec.709 while this problem is being fixed, but grading in SDR might be needed temporarily.

Jan 11, 2025 6:38 AM in response to joema

QUOTE joema

As you said, it shouldn't be necessary to shoot in an SDR format such as Rec.709 while this problem is being fixed, but grading in SDR might be needed temporarily.

UNQUOTE


Thanks for this ! So you mean, I could still shoot in HDR, import and process my clips in an SDR library and export the project in Rec.2020?

Jan 11, 2025 7:52 AM in response to AlainBE

If you are shooting on an iPhone, shoot Apple Log and you are covered now and in the future (as Joema describes also). The philosophy is to capture the maximum possible and work down from there. You can grade in SDR if necessary of course.


I got an iPhone 16 Pro, the first iPhone I've gotten that is capable of shooting decent video a few months ago, and I've done a lot of experimentation.  I find the HDR HLG modes produce very over-processed images (video and stills). They look great on a phone but on a larger monitor they look way over-sharpened. 


On the contrary I was very pleased to find that Apple Log produces very high quality video that looks really natural. You can use LUTs when shooting that allow you to see what you are shooting in HDR. There is a fantastic 3rd party app called Cinema P3 on the App Store that adds some extras not available in the built-in app or in the Blackmagic app for that matter. There is a couple of cheap in-app purchases that are well worth the small cost, including an excellent set of LUTs for easy viewing of Apple Log video. 


If I were in your situation, I would downgrade to Sonoma for sure. If you don’t want to do a full reinstall, you could install it on an external SSD. This is what I did with Sequoia to reply to your original question. It was only after a few months that I installed Sequoia on my work machines.

Jan 13, 2025 2:16 PM in response to AlainBE

After my post last week, I've spoken with support a couple more times, and they asked if I could send in some quick details of what others here in the forum are experiencing, along with the model of their monitor, Mac, connection type (Thunderbolt/HDMI...) and a little about the Library/Project type and the video/clip type (iPhone HLG, etc...). They prefer the issue to be happening with iPhone footage since it's their own product.


Support wants to show engineering the issue is happening to more people than me alone, and the more examples they have, the more they might try to fix it.


Also, if you haven't contacted support about this, please do so. Hearing from others helps them know it's a real issue and not just a fringe issue affecting a small minority.


I WILL NOT include your username or any personal info, just the info about the problem.


I'll give it a few days for people to post their info and then send an email to support on Thursday, 1/16/25 at 10AM EST.


For me, I'm including this in my reply. Feel free to copy my "template" and just change any relevant info.


ISSUE: In an HLG project, all clip types (Rec.709, HLG, PQ) appear dark in the viewer when hovering over them in the browser and timeline. In a PQ project, the same clips appear dark in the viewer when hovering over them in the browser, but they appear correctly in the viewer when hovering over them in the timeline.

MACOS VERSION: Sequoia 15.2

FCP VERSION: 11.0

MACHINE: M1 Mac mini

CONNECTION TYPE: HDMI

MONITOR: LG C3, 42”, model OLED42C3PUA

ALSO TESTED WITH: Dell S3220DGF, LG 32GS95UE-B and a Sony BVM-X300 (Connected directly to the HDMI port on the monitor - NOT going through a Blackmagic Ultrastudio type device)

LIBRARY TYPE: Wide Gamut

PROJECT TYPE: HLG & PQ

FOOTAGE: Happens with ALL footage types (Rec.709, HLG, PQ) taken with iPhone 13 Pro Max and all other camera brands/models


Thanks!

Mark


Jan 13, 2025 2:34 PM in response to IAmSkippermark

Mark, thanks for all the work on this. I did some testing today and started getting set up to debug it with XCode.


That will take at least a couple of days. I will need to create a Sonoma boot disk so I can do comparative tests between Sonoma and Sequoia. If successful, I'll file a bug, post the results here, and discuss the details with other industry contacts.


I tested it today with the Atomos Shogun 7 monitor, which is supposedly HDR. It showed "wrong" behavior but in a different way -- with the HDR setting enabled in MacOS System Settings>Display, and with the Shogun 7 set for Rec.2020 HLG or PQ and HDMI input, the image became too light, not too dark.


If anyone with a Shogun 7 has reproduced the typical "too dark" behavior, let me know the specific Atomos and MacOS settings.

Jan 15, 2025 9:47 AM in response to AlainBE

I thought most people would want to reply to the discussion here, but I just posted with an email address if someone preferred that, but the post was deleted because it contained personal info...a.k.a. the email, so I guess the only option is to post it here.


In that post, I also said that I had offered to provide the link to this discussion to support, but they didn't want it because it's not an official means of support.

Jan 16, 2025 11:15 AM in response to IAmSkippermark

Thank you for your efforts. Here is a resume of my contribution.


ISSUE: since I upgraded to Sequoia, HDR videos shot on an iPhone 14 Pro Max  and 16 Max Proappear 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.

MACOS VERSION: Sequoia 15.2, but problem appeared with 15.0

FCP VERSION: 11.0, but problem appeared in FCPX

MACHINE: M2 Pro Mac mini

CONNECTION TYPE: Thunderbolt 4

MONITOR: LG 40WWP95C-W (HDR enabled in MacOS)

LIBRARY TYPE: Wide Gamut

PROJECT TYPE: HLG

FOOTAGE: Happens with ALL footage types (Rec.709, HLG, PQ) taken with

iPhone 14 Pro Max and 16 Max Pro

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.