When using Final Cut Pro's built in "Save Current Frame" option, the exported frame is darker than the original no matter what format the file is saved in. Obviously they should look exactly the same. I assume this is a bug because why would they do this on purpose? Screenshotting will get around this but it can be difficult to screenshot the viewer at 100% size and perfect dimensions. Shouldn't have to rely on that anyway.
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.
It is impossible to judge without knowing the detailed specifications for verification. Mac model, FCP version, media details, library and project settings, effects, etc.
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
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”.
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
Ian, an example of why I might need to Save Current Frame would be to touch it up in Photoshop... such as to remove an object in a stop motion animation that only appears for one or two frames to prop something up, etc.
Joe Redifer wrote:
Ian, an example of why I might need to Save Current Frame would be to touch it up in Photoshop... such as to remove an object in a stop motion animation that only appears for one or two frames to prop something up, etc.
In that case, and while we wait for a fix, you may want to try the workaround that I described earlier.
If you don't mind buying a plugin you can get a clone/delete tool from Dylan Bates.
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's not unpredictable, however. It happens every time. I think a report of "Save Current Frame always has a gamma shift in Sequoia . Every time, no matter what. Try it yourself, you'll see."
If that's not enough for Apple I weep for the industry.
Ian, that looks like a good plugin, but I'd need much more finesse that only Photoshop can provide for such a task.
Final suggestion . . . download the free version of Resolve and see whether that is any better.
I didn't have time to check properly but now I have it is perfect . . . absolutely no difference when stepping through the timeline frame by frame.
Ian,
I have the studio version of Resolve but despite having used it many times I still haven't wrapped my head around it yet. It's not designed intuitively.
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.
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.
Gamma shift when using Save Current Frame. Why?
