libultrahdr
libultrahdr copied to clipboard
Strange inexplicable banding
I am trying to make an ultrahdr jpeg version of this test image:
As inputs, I'm using this DisplayP3 SDR image input_sdr.jpg:
and this P3 PQ version of the original HDR image, ITU-R_BT.2111-2-Test_pattern_PQ_full_range.png.raw:
ITU-R_BT.2111-2-Test_pattern_PQ_full_range.png.raw.zip
Then I run this command line:
ultrahdr_app -m 0 -a 5 -t 2 -C 1 -w 1920 -h 1080 -c 1 -R 1 -s 1 -Q 95 -M 1 -L 2000 -p ITU-R_BT.2111-2-Test_pattern_PQ_full_range.png.raw -i input_sdr.jpg -z output_ultrahdr.jpg
The result I get is this:
The colors seem to be more or less correct, but there are strange noticeable elliptical banding patterns in the solid color regions and I don't understand what is causing that. I would expect regions of solid color to remain flat.
Is there something in the computation of the gain map from the SDR base and the HDR alternate images that is not just a per-pixel thing and that could introduce this kind of banding?
On photographic images I am also getting banding artifacts in the skies that seem like they should be avoidable, for example:
@jonsneyers The banding in the test chart is entirely in the gain map. The free Adobe Gain Map Demo app is a quick and powerful way to troubleshoot things like that (click the gain map radio in the app and you'll see it - the numeric readouts as you however the image show the linear gain).
Your base image is using some less common color encoding. I'd try sticking with the basics for sRGB / P3. Not sure it matters here, but it's a variable I'd eliminate for troubleshooting.
quick suggestion, the base image chroma components are very heavily quantized. Even though visually the bars look uniform in color, histogram of individual color bars have large variances. For instance the yellow bar in (col 3 from left). This may be causing banding. Can you try by increasing the base image quality
I tried again with this base image, which was encoded using ImageMagick convert -quality 100 (i.e. libjpeg-turbo, 4:4:4, quantization tables all 1s).
The result is this:
Bumping up the gain map quality to -Q 100 instead of the -Q 95 I was using before also doesn't help, it produces this:
What I don't understand is why one 8x8 block that has only a single color would become different from another identical 8x8 block of exactly the same color. That would not be something caused by JPEG artifacts.
thank you for sharing the images, yes i could see clear banding in gainmap image. will take a closer look.
I believe this issue is also mitigated by PR #358. When the R, G, or B values of the SDR or HDR image are extremely small, the gain is calculated to be very large, which results in a wide range of GainMapMin and GainMapMax values—specifically, -14.3 and 5.64168. This significantly reduces the precision of the gain map image.
The image below was converted using ultrahdr_app with PR #358 applied. In this image, the GainMapMin and GainMapMax values are -6.89226 and 5.63464, respectively.
Regarding the cause of the elliptical Mach bands, I believe the issue lies in input_sdr.jpg. The following image has adjusted gamma and contrast to make the Mach bands present in the SDR image (https://github.com/google/libultrahdr/issues/357#issuecomment-2841066262) more visible.
Thanks for the insights — I guess the bands are an artifact of the tone mapping I used to produce the SDR image then, and can probably be avoided by using some simpler tone mapping (I used local tone mapping but global tone mapping will not have this effect).
It's just a bit surprising to me that the banding is not visible in the SDR image but it does become visible in the reconstructed HDR image, even though in principle the gain map (being a 3-channel 4:4:4 high-quality gain map) should be able to 'correct' any defects in the SDR image.