Gamma shift when using Save Current Frame. Why?

Joe Redifer wrote:

In the meantime the easiest and fastest workaround I've found is to just convert the image to the REC 709 Gamma 2.4 profile in Photoshop which fortunately can be automated so it's literally one click.

Just have to figure out why FCP wants to export as BT.709-5. I'm surprised FCP even knows how to do that.

I think the issue Joema is describing is completely separate from your problem which I think is actually a non-issue if you set up Photoshop properly in order to work with images from other apps such as FCP. Converting to the profile that that image is tagged with is what you are supposed to do if you want the image in Photoshop to look the same as in FInal Cut Pro. This is how color management is supposed to work.

However, you should not be doing this manually for each image. It is much easier to set your Color Management Policy to Preserve Embedded Profiles in the Photoshop Color Settings (towards bottom of Edit Menu) which is generally the best way to set up Photoshop anyway unless you have a reason not to do so. I am not seeing any gamma shift when exporting current frame and opening in Photoshop when set up in this way.

It would be surprising if FCP did not tag an exported still with the same color space as the timeline. If the project is SDR, it will use REC709. If the project is HDR, it will use a REC2020 tag. Again this is how it is supposed to work.

However, I am seeing the changes that Joema is talking about when viewing images in Preview but that is not the issue for Joe R if you want to edit frames in Photoshop and return them to FCP in the same color space.

In my tests, doing a screen capture instead of FCP Save Current Frame avoids the problem. A screen capture can be done in jpg, png, tiff, heic, etc.

Screen captures on MacOS default to PNG, but you can change that with these terminal commands. These are safe and have been used for many years:

defaults write com.apple.screencapture type jpg

killall SystemUIServer

Once changed, this format is also used by the MacOS GUI screen capture interface (CMD+OPT+5).

To capture a frame from MacOS, just display it full screen in the viewer, make sure the controls are not showing at the bottom and do CMD+OPT+3.

Another option is use the free command-line tool imagemagick to edit the embedded color profile. Using an ICC profile instead of the hard-coded 'Rec. ITU-R BT.709-5' used by FCP's Save Currrent Frame seems to avoid the problem. Imagemagick is available through the Homebrew package manager. Example syntax:

magick convert input.jpg -profile /path/to/profile.icc output.jpg

You can search your system for what ICC profiles are available. Note: some locations may not be indexed by Spotlight, so you'll have to do a non-indexed search from terminal or use a third-party search tool like EasyFind. Examine of terminal search syntax:

sudo find / -name "*.icc" -o -name "*.icc" 2>/dev/null

I can't finish the research on this issue and talk to Apple until next week because I'm on an editing deadline. This problem is very finicky and unpredictable, so a well-bounded, high-quality bug report is better than a vague bug report. If the problem is clearly defined, there's a much greater chance Apple will move quickly to fix it.

It appears this behavior was reported in the Apple MacOS forum on Sept. 23, 2024 and possibly reported via the Apple feedback system. It's obviously not fixed, possibly due to a poorly-described scenario: macOS Sequoia Bug - Preview misinterprets… - Apple Community

Anybody who wants can report this (again) via the Apple feedback web page: Feedback - macOS - Apple

However, testing on multiple machines shows the behavior is quirky, has state dependencies and may involve both video and still-image metadata. There are several software layers below what you visibly perceive that involve how ColorSync works with embedded color profiles and display profiles on various hardware and MacOS versions.

I and a colleague who is an expert on MacOS ColorSync recently spent several hours on a Zoom conference studying this issue. During that conference, the problem vanished on one of my Macs, then later reappeared. We intend to pursue this next week.

The problem is apparently related to the embedded color profile 'Rec. ITU-R BT.709-5' used by FCP when doing Save Current Frame from a Rec.709 project. By contrast, Resolve (despite exporting from a Rec.709 timeline) uses the embedded profile 'SRGB IEC61966-2.1'. This doesn't mean FCP's use of that particular BT.709-5 profile is wrong but more likely, how ColorSync handles it is wrong. So it's likely not a bug with Preview or Quicklook or FCP but a deeper MacOS problem.

As described above, the frame exported from FCP can be patched using the command-line tool ImageMagick to have a regular ICC-type Rec.709 profile, which seems to avoid the problem.

It's possible to automate that via a MacOS shortcut, whereby it monitors an output folder for .jpeg files from FCP, then automatically patches them. I don't have time right now to produce that, but it should be straightforward.

Also as described above, it's possible to take a full-screen capture of the FCP viewer so that it's dimensionally perfect, and without drawing a capture box by hand. That also works around the problem. However, when going to full screen, FCP playback immediately starts from the current frame.

To prevent this, you can do the command sequence I, <right arrow>, O,/ (I key, right arrow key to advance on frame, O key to mark end of 1-frame range, forward slash key to loop on that one frame, then SHIFT+CMD+F for stationary full-screen viewer on that frame, and SHIFT+CMD+3 to capture that). That can all be automated via a MacOS shortcut, at least to some degree. I have a provisional Shortcut + AppleScript that does that, but I want to test the usage on various machines before I post it.

Just an addition to my earlier post. Opening the saved frame image into Photoshop with Color Management Policy set to Preserve Embedded Profile and it looks the same as it did originally in the FCP timeline as I said in the previous post.

However, if this image is saved with the Rec. ITU-R BT.709-5 tag (which happens if you work on the image and resave it) and then import it back into FCP, it will show as darker than the original. So it is necessary to use the Convert to Profile command to tag it as REC709 (the Gamma 2.4 is not necessary before saving and then reimport it into FCP if desired which I guess is what Joe R (the OP) meant in his previous post.

Similarly if you re-import the original exported frame tagged Rec. ITU-R BT.709-5 into FCP, it shows up darker than the original frame in the timeline. I'm not clear if Joema is aware of this but it implies that FCP is also incorrectly interpreting its own exported frame. In other words, this behaviour is not restricted to Preview or Quick Look, it is also happening in FCP. I've not checked Motion but I would bet it is the same. However, Photoshop is not misinterpreting the Rec. ITU-R BT.709-5 tag.

EDIT - Motion is doing the same thing - interpreteting images tagged Rec. ITU-R BT.709-5 as darker than they should be. It looks like a stop darker in all cases - not verified this.

Joe, this is a known issue I am investigating. Apparently, starting with Sonoma (for sure on Sequoia), the behavior of the embedded Rec. ITU-R BT.709-5 profile in "Save Current Frame" for jpeg, png and tiff changed when viewed using Quick Look or Preview. It typically manifests as increased gamma. The embedded color profile can be viewed in Preview by doing CMD+I. The display profile used doesn't make any difference.

The behavior is quirky and state-dependent. In Preview if you place the mouse cursor on the title bar and then move the scroll wheel up and down, it may jump between two different gamma levels. In Quick Look if using cursor keys to go up and down in Finder's List View between different "Save Current Frame" still images, it can depend on the embedded color profile in *adjacent* images. E.g, if you have adjacent screen captures and "Save Current Frame" exports, depending on the sequence and cursor direction, the behavior can vary. The fluctuating gamma aspect does not require a mouse but also happens with the scroll gesture on trackpads.

There might be a related problem whereby gamma can fluctuate if the mouse cursor is scrolled on the title bar of Quicktime player during playback of some Rec.2020 HLG videos, but it's less obvious.

I've reproduced it on M1 Ultra Mac Studio using both Apple Studio and LG 5k Thunderbolt monitors, M1 Max MacBook Pro 16, and a 2019 i9 MacBook Pro 16, all running Sequoia 15.2. It does not happen on Ventura 13.7.2 on a 2017 iMac 27.

I only discovered this over the weekend and am still doing tests, so I haven't called Apple Support yet.

The only workaround I know is doing a screen capture, not a Save Current Frame. Screen capture uses the currently-installed ICC color profile, not the hard-coded BT.709-5 profile.

Note that some newer Macs have a different color profile system, but they can still use the older ICC system if you select those color profiles with ColorSync Utility: REC 709 display issue on macOS Sequoia wi… - Apple Community

It's not FCP misinterpreting the image file -- it is MacOS. FCP 10.8.1 on Sequoia 15.2 shows that darker image file appearance upon re-import. FCP 10.8.1 on Ventura 13.7.2 does not do that.

The reason Photoshop appears to work is because the display aspect is not color-managed in a MacOS environment. If configured to use the Apple Color Management Module, that is only for file-to-file conversions, not for how it displays images on the screen. The problems you see with items displayed by Preview and FCP are likely related to the ColorSync display match system, triggered by the BT.709-5 embedded color profile.

I think FCP's Save Current Frame works OK on HDR video frames exported as still images.

I did some more testing today exporting to jpg, png and tiff using an embedded Rec2020 HLG profile and comparing that to the video on the same screen in the FCP viewer, Quicktime and Preview. I tested multiple display profiles on three monitors: Apple Studio, LG 5K Thunderbolt and XDR 1600-nit display on an M1 Max MBP 16. I got inconsistent results. It worked perfectly on the MBP 16 XDR 1600 nit display -- if using the P3-1600 nit profile. IOW the still image was identical to the HLG video frame.

It worked less well (IOW more visible still vs video differences) using the P3-600 nit profile on the Apple Studio display, and less well using a Rec.709 120 nit gamma 2.4 profile on the LG 5K.

The Apple displays introduce yet another factor, which I think is their EDR technology. It's especially obvious on the MBP 16 XDR 1600 display. The viewport showing the HDR material is much brighter than the surrounding UI, and the brightness fades up over an approx 1 sec interval upon showing the HDR content, then fades down when that content is removed. It looks good but I have no idea how that could be calibrated. There are several WWDC seminars on Apple's EDR (Extended Dynamic Range) technology. It's not just hardware; there are APIs also.

So several monitor types behave differently: non-Apple SDR, non-Apple HDR, Apple SDR, Apple HDR, and other variations in between. The Apple monitors are also classified by whether they only accept ICC profiles or use the new "reference preset" system.

Yes, this a problem in 11.0.

As Ian said, it is easy to avoid it if you don’t need that image outside FCP.

If you do need it, a workaround is to instead export a movie with just one frame, then open it in Quicktime Player; Copy; switch to Preview and press Command-N for “new from clipboard”.

JPG and TIFF images exported from FCP 10.6.5 on Ventura 13.7.2 use the same BT.709-5 embedded color profile. Those files, if copied to a Sequoia machine, show the same problem in Preview, QuickLook, ColorSync Utility and even the third-party "Screen" app. This implies it has nothing to do with FCP -- it's been using that embedded profile for Save Current Frame for years. The fact it happens with other utilities implies it's not a "Preview problem", rather it's a deeper MacOS issue.

There was apparently some change in Sonoma or Sequoia in how jpg, jpeg, png and tiff images having a Rec. ITU-R BT.709-5 embedded profile are displayed by some utilities. Only the BT.709-5 profile started causing problems with Sonoma or Sequoia; other ICC-type Rec.709 embedded profiles work OK.

The XCode Instruments tool shows that Preview (and probably the other affected apps) is doing lots of color validation calls when handling an image file with the BT.709-5 profile. Those calls don't happen when the image file contains a Rec.709 embedded ICC profile.

The question obviously arises, since the BT.709-5 embedded profile has existed in FCP image exports for years, why only now is it a problem? This week I'll try to get an Instruments trace from Preview on a Ventura machine handling the same file and compare that to the Sequoia trace.

The current problem with Preview, QuickLook, etc, only happens with the embedded ITU-R BT.709-5 profile, which by itself is OK. The problem is from how code paths starting with Sonoma/Sequoia began interpreting differently that one specific embedded profile when handling image files. It has to be fixed at the level of whatever MacOS framework is causing it, because it's not feasible to change every image display app, including third-party apps.

joema wrote:

I think FCP's Save Current Frame works OK on HDR video frames exported as still images.

Yes I rechecked and you are correct. There is no change when saving current frame as Rec2020 PQ. This is only an issue with Rec709 projects.

Also the workaround for Rec709 projects by opening the image in Photoshop and converting the tagged proflle works but does require conversion to Rec709 Gamma 2.4. Simply converting to Rec709 doesn't work - I was incorrect above.

If you don't mind buying a plugin you can get a clone/delete tool from Dylan Bates.

https://thefinalcutbro.gumroad.com/l/clonestamp

Mine also seems a tad darker or richer colours but I wouldn't lose any sleep over it.

If you intend to use the .jpg in the timeline it's much quicker and easier to make a freeze frame . . . press Option-F

It is impossible to judge without knowing the detailed specifications for verification. Mac model, FCP version, media details, library and project settings, effects, etc.