Colour conversion issue

[Walnut]

Hi,

I'm compressing 4K movies, and converting their colour space as well. I convert from YUV to Reinhard. Everything is fine, except for one issue. When the light becomes very strong, like there's thunder or something exploding, and the screen becomes white for a brief moment - once the file got converted to Reinhard, it becomes gray, which looks super weird in a movie. Anyone knows how I could fix that?

Thanks!

[eumagga0x2a]

In other words, you re-encode HDR source using "RGB Reinhard" tone mapping option in Avidemux (with dynamic tone mapping enabled or disabled?) to SDR. While I cannot help with fixing tone mappers, obtaining a short sample, saved in copy mode, as well as an Avidemux project script recording the actual configuration used to process the source, would be necessary to assess the situation. Please provide the sample preferably via WeTransfer, Mega, Dropbox or Google Drive.

You might also try other algorithms, maybe they work better for you.

[Walnut]

Thanks for your reply!

Yes, I re-encode HDR source using "RGB Reinhard" tone mapping option to SDR, with dynamic tone mapping enabled.

I'll send the sample and the project script recording on Friday morning (right now avidemux is busy re-encoding a film, should be done by Friday morning).

[Walnut]

Here are 2 samples, the settings I used and the Avidemux project script recording of another movie I just re-encoded (I don't have the project script recordings of the movies the samples are from):

wetransfer.com/downloads/c90d080f57c2ee79caba89a5c444f46920240802053746/a02e2b

[eumagga0x2a]

Thank you for samples. Unfortunately, you haven't provided a sample saved in copy mode (both are re-encoded). It is similar to assessing health of a cow based on a roasted steak and a cooking recipe. However, in this case, I believe that you have caused this issue by reducing boost down to 0.20. What was the reason to choose such a low value?

With boost set to a more reasonable value close to the default (1.00), I would also suggest choosing "Clipping" for "RGB out of gamut handling".

[eumagga0x2a]

Judging by ineffective and pointless "high444" profile (removed two years ago from code) in the x264 configuration on your third screenshot, you probably use the 2.8.1 release which has got really long in the tooth. By all means, you are probably better off using a recent 2.8.2 nightly build.

[Walnut]

Thanks for your reply! I'll follow your advice and use a more recent version, as well as the "Clipping" setting.

I reduce the boost level down to 0.20 because when HDR gets converted to RGB Reinhard, it gets much brighter than the HDR source file. When the boost level is down to 0.20, then it matches the colour timing of the original HDR file. Is there another way to adjust the brightness?

Regarding the samples, so I should send samples of the original HDR files?
(I sent samples of the re-encoded files for you to see what happened, this gray screen thing)

What profile should I use instead of
"High444", to get the highest quality possible?

Thanks again!

[eumagga0x2a]

I reduce the boost level down to 0.20 because when HDR gets converted to RGB Reinhard, it gets much brighter than the HDR source file. When the boost level is down to 0.20, then it matches the colour timing of the original HDR file. Is there another way to adjust the brightness?

Can't recommend you anything without having played with the source video. With HDR samples currently available to me, boost values close to 1.0 provide the best match.

Regarding the samples, so I should send samples of the original HDR files?

Yes, please, as requested:

obtaining a short sample, saved in copy mode [...] would be necessary to assess the situation.

What profile should I use instead of
"High444", to get the highest quality possible?

You should use the ordinary "high" profile (some recommend "high10", but the input to encoder remains 8-bit, so not sure what improvement the 10-bit mode may provide beyond reducing compatibility of the compressed video stream with various hardware decoders). The "high" profile was also what you were actually getting.

I would also suggest reducing the number of reference pictures for the same reason of limited compatibility (unless you re-encode the video for hardware you know is capable of decoding the stream).

[Walnut]

Thanks!

Here are the samples from the HDR sources: wetransfer.com/downloads/6691fca6501ca6d1c6411ec76cb7736220240806094315/17dbc8

I just ran a few tests. I used for all of them the latest nightly build for Avidemux 2.8.2 (for macOS monterey), the "high" profile and the "clipping" option. I tried:

- RGB Reinhard + boost level 1.00
- RGB Reinhard + boost level 0.20
- RRGB Hable + boost level 1.00
- RGB Hable + boost level 0.45

Each time the result is the same as previously: it becomes gray instead of white.

Then I ran an additional test:

- RGB Reinhard + boost level 6.00 + I ticked off the RGB tonemappers.

In that case only the white flashing light remained white. But the colours didn't look as faithful to the source as with the tonemappers on.

How do you reduce the number of reference pictures?

[eumagga0x2a]

I confirm the issue with adaptive mode in HDR tonemappers, no matter which algorithm. Nothing short of disabling it helps. mpv can be used as reference, displays colours correctly.

I am sorry for bad news, but if "Fast YUV" algo results in colours being too much off, I don't see a viable workaround before the bug is understood and an accurate implementation written.

How do you reduce the number of reference pictures?

I see, the number of reference pictures goes up the slower x264 preset is (5 with "slow", 8 with "slower" IIRC). It can be controlled by using advanced x264 configuration, but if the setting doesn't cause problems for you then let it be. Computationally more expensive presets provide higher compression, they are not that much for improving quality.

[Walnut]

Thanks for your reply, despite the bad news, and fingers crossed this issue can be solved (I realised there are quite many movies with such white flashing moments). Will there be a way for me to know it, once this bug will have been fixed?

Unrelated question: when I re-encode a long film (2 hours or more), it looks like the 1st pass is slowing down while happening. For instance, based on what the "Time remaining" thing shows, looks like it takes 12 hours to complete 50% of the 1st pass, and then 17 hours to complete the remaining 50%. Any issue there? Or is it just the "Time remaining" thing being not that accurate?

[eumagga0x2a]

Why do you use multipass encoding in the first place? Unless you have strict output size restrictions to comply with, I would recommend to use the constant quality mode. I could imagine that the hardware overheats and is throttled down by the operating system. 12 hours for the first pass? Have you got Avidemux running on a TI calculator from the Eighties? Just kidding, but this feels wrong on so many levels...

Regarding a fix for tone mappers which is not about to come any time soon, please disable adaptive mode for now. This is the best workaround I can recommend for these samples.

[Walnut]

Thanks!

I was using multipass encoding because I'm both converting colourspace and compressing. This way I can decide the size of the re-encoded file. I will try the constant quality mode. Just ran a few tests with different quantizers, I think I understand now how to set them in order to get the size I want, while preserving high quality.

I will try disabled tone mappers too.

[eumagga0x2a]

Please do not disable tone mapper, but disable the adative mode for the algorithms operating on RGB pixel formats.

[Walnut]

Just to be sure I don't make any mistake - where do you disable the adaptive mode?