Issues with HDR Tonemapping / HDR Tools useless?

Question

Level 1

86 points

Issues with HDR Tonemapping / HDR Tools useless?

So I'm trying to use a clip that was recorded in HDR from a PlayStation 5 onto an Atomos Ninja V+ in a Final Cut Pro REC 709 project, but it looks all sorts of washed out. FCP only allows me to select up to REC 2020 stuffs, I guess it's not advanced enough for REC 2100? It interprets it at 2020 PQ but Adobe Premiere says it's REC 2100 PQ. Not sure what the difference is. Using the HDR Tools effect doesn't do much no matter which setting I choose.

Here's what the clip looks like simply dragged to the timeline, letting FCP automatically do it's own thing. This is as good as it gets but the blacks are still way too bright.

Here's the HDR Tools effect applied. Doesn't help. Not sure why this effect exists.

Here's what is SHOULD look like. This is a REC 709 recording of the same screens. Proper tonemapping should approximate this very closely.

Someone created some generic HDR-SDR LUT as a .cube file and it works OK in Premiere. That same .cube file in Final Cut Pro doesn't do anything similar which leads me to believe that Premiere and FCP handle color and LUTs VERY differently, not sure which one is handling them wrong. Both NLE's were operating in a 709 color space.

Anyway if anyone wants to mess around with the HDR file, here's the download link. I also included the REC 709 file for reference as well as the HDR-SDR LUT which works OK in Premiere but washes things out more in FCP for some reason. If you can get it to match, please tell me what I'm doing wrong!

Video Files - 2.98 GB

Posted on Dec 16, 2024 6:29 PM

Reply

Answer 1

joema

Level 2

483 points

Dec 17, 2024 3:54 PM in response to Joe Redifer

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

Reply

Answer 2

Joe Redifer Author

Level 1

86 points

Dec 17, 2024 5:51 PM in response to joema

Very interesting!

FFMPEG seems to be unnecessarily convoluted. I can't even paste your syntax in. How is it used? Is there a GUI or a better way to do this without command line?

Reply

Answer 3

Joe Redifer Author

Level 1

86 points

Dec 17, 2024 6:00 PM in response to Joe Redifer

Unfortunately in HDR you can not enable/disable legalize on the Atomos Ninja V+

Reply

Answer 4

Joe Redifer Author

Level 1

86 points

Dec 17, 2024 6:17 PM in response to Joe Redifer

OK I found an app called FF-Works. I could paste your commend line in there and changed the 2100 video to Limited without re-encoding. It still looks extremely washed out.

Reply