Issues with HDR Tonemapping / HDR Tools useless?

After doing the above commands, on my machine the viewer display and the luma waveform are quite similar if the Rec.709 and Rec.2100 PQ clips are fixed with the above FFmpeg commands to correct the wrong metadata range values, and if Rec.709 and Rec. 2100 PQ clips are played in an SDR project and SDR timeline.

However there are other issues. Further study shows the Rec.2020 PQ file is only 8 bits per channel, but the metadata flag says "full range." Examination of the Y'CbCr encoding of the file shows the max Y value is only about 172 on a range of 0-255. Since Rec.2020 PQ really needs at least 10 bits per channel, the file will never look that good and may be subject to artifacts.

So the HDR file appears encoded as limited range and 8-bits per channel, but in a container that requires 10-bits per channel, an it's erroneously tagged as full range.

By contrast, the Rec.709 file is 10-bits per channel and the data is encoded using full range code values, but it has no full range metadata flag, which by convention is considered a limited range tag. So this file's encoding violates the limits for limited range.

The attempts to fix this using FFMpeg are only a Band-Aid, and should not be required. It may not even be possible to fully fix it unless the encoding issues with the files are corrected.

Is your goal to have mixed HDR/SDR content in an SDR library and SDR project? If not, please clarify. In your scenario, why do you have a mix of HDR and SDR from the same source material, and what is your ultimate goal? E.g, is some source material only available in HDR or SDR, and you have to mix them in an SDR timeline?

If the PS5 can output SDR to HDMI, you could try that. If you need to intermix HDR and SDR content on an SDR timeline, that is possible, but it really requires properly-encoded files with correct metadata.

The MediaInfo tool will show the bit depth and in some cases the range levels. If it says "full range" the file should be encoded full range. If it says "limited range" (or if range is missing) the file should be encoded limited range.

The range values can be examined using the free third-party tool QCTools. The legal luma code values for 10-bit limited range are 64-940 and for 8-bit limited range is 16-235.

None of this is really an FCP issue, rather the file encoding and metadata are incorrect.

I believe the Astro Bot 709.mov file is encoded with full range code values, but not tagged with "full range" metadata. It has no range tag, but by convention, no tag means limited range. Examining the max encoded Y value shows it is well above the legal 10-bit code value range of 940, therefore we must assume it is full range but without the appropriate tag.

The Astro Bot 2100 PQ.mov file seems encoded with limited range code values, but is tagged as "full range". With few exceptions, most video is encoded as limited range, not full range. Relative to the other clip the code values are much smaller, implying the same scene was encoded for limited range.

If I use FFMpeg to copy the files without reencoding, changing only the limited vs full range metadata tag, they look quite close in an SDR library and SDR project.

Metadata tags should always match the characteristics of the associated video. I believe Atomos devices have a legal vs data (aka limited vs full range) parameter. If it's not set correctly the file will not be tagged properly.

Syntax to change limited range tag to full range for Astro_Bot_709.mov:

ffmpeg -i Astro_Bot_709.mov -c:v copy -bsf:v hevc_metadata=video_full_range_flag=1 -c:a copy Astro_Bot_709_Full.mov

Syntax to change full range tag to limited range for Astro_Bot_2100_PQ.mov:

ffmpeg -i Astro_Bot_2100_PQ.mov   -c:v copy -bsf:v hevc_metadata=video_full_range_flag=0 -c:a copy Astro_Bot_2100_PQ_LimitedRange.mov