Please add ultrahdr_app flag to allow customized minContentBoost / maxContentBoost

[gregbenz]

For some images, it would be ideal to have control over minContentBoost and maxContentBoost. It would be ideal to be able to pass a float value to ultrahdr_app to override the defaults (

libultrahdr/lib/src/jpegr.cpp

Line 953 in 0f97353

metadata->maxContentBoost = hdr_white_nits / kSdrWhiteNits;

).

For example, the default min prevents the HDR from being darker than the SDR. While that sounds reasonable, there are reasons not to enforce such a clip. If the two images are derived independently, this may be a real scenario where some HDR pixels are a bit darker and enforcing a minimum would result in unexpected lifting of HDR shadows (ie loss of contrast/detail in the rendered result).

If a range check is needed for these values, I would propose allowing any positive float value to offer maximum flexibility (unless I'm overlooking the impact of future cases where the base image is HDR and the gain logic is flipped). There are a wide range of useful values for some niche applications.

[pmonck]

Furthermore, does this code confirm my suspicion that the metadata.cfg supplied when using API - 4 has no effect on the output?

[ram-mohan]

@pmonck in api-4, the gainmap image, sdr intent and gainmap metadata, alll these are combined to create an ultrahdr image. This api has a write through effect and no processing/corrections of the data provided is done. metadata.cfg does have effect, where its contents are written in xmp block of jpeg image.

[GrousexyHKCN]

hi guys, i also found something strange might be related to this topic.
when i used API4 to generate ultra hdr image with ultrahdr_app -m 0 -i input_sdr.jpg -g input_gainmap.jpg -f metadata.cfg -w width -h height -q quality the details of metadata.cfg as shown in the first image
;

however, when i used exiftool -b -MPImage2 ultrahdr.jpeg>gainmap.jpg and to check the metadata of the gainmap, the metadata is different from what i used in metadata.cfg, like this image

so i wonder the how **real metadata ** that have impact on hdr appearance is calculated or encoded?

[GrousexyHKCN]

What's more, even i used other image and different metadata written in metadata.cfg to generate ultrahdr image by API4, the extracted gain map would still showe 2 for gainmapmax, 0 for gainmapmin, it seems that the metadata is fixed in API4

By the way when i use API0 or 1, the metadata is shown as

the value 2.30045 which i believe is what @gregbenz post in the question equals to log2(hdr_white_nits(1000) / kSdrWhiteNits(203)). also, those metadata values are fixed for any inputs i make.

[ram-mohan]

however, when i used exiftool -b -MPImage2 ultrahdr.jpeg>gainmap.jpg and to check the metadata of the gainmap, the metadata is different from what i used in metadata.cfg, like this image

@GrousexyHKCN From ultrahdr_api.h,

/**\brief Gain map metadata.
 * Note: all values stored in linear space. This differs from the metadata encoded in XMP, where
 * max_content_boost (aka gainMapMax), min_content_boost (aka gainMapMin), hdr_capacity_min, and
 * hdr_capacity_max are stored in log2 space.
 */

So the exiftool findings and cfg file are in sync (just that they are in different scales as indicated). Further api-4 combines all the information provided (sdr intent, gainmap image, metadata), hence these configs -w width -h height -q quality are not used.
ultrahdr_app -m 0 -i input_sdr.jpg -g input_gainmap.jpg -f metadata.cfg should be enough

What's more, even i used other image and different metadata written in metadata.cfg to generate ultrahdr image by API4, the extracted gain map would still showe 2 for gainmapmax, 0 for gainmapmin, it seems that the metadata is fixed in API4

This may not be true, can you please share the sdr intent, gainmap and metadata used for this.

the value 2.30045 which i believe is what @gregbenz post in the question equals to log2(hdr_white_nits(1000) / kSdrWhiteNits(203)). also, those metadata values are fixed for any inputs i make.

This will be addressed once this is merged, #215

[ram-mohan]

These changes are merged.

[ram-mohan]

@gregbenz Did you mean "the default min prevents the HDR from being darker than the SDR."

[gregbenz]

@ram-mohan yes, sorry for that confusion. I've edited my original post to correct that.

[ram-mohan]

@gregbenz, thank you for pointing out the limitation in the current choice of gainmap min and max content boost. The very initial versions allowed for a much large swing (both positive and negative values). For simplistic reasons it was clamped to current choice of values. We are currently working on few changes that would allow for negative content boost values to handle for the scenario "HDR pixels are a bit darker" better.

As per your suggestion, we have also added an api that allows for configuring hdr mastering display in nits.

Currently we are computing min and max content boost internally and using those values. Although allowing the user to configure these values would be handy, I feel its best if library computes these values on its own.

[gregbenz]

@ram-mohan Thank you for all your hard work and continuous improvements!

[ram-mohan]

The change is merged. #244
@gregbenz If there is nothing pending here, this can be marked for closure.

[gregbenz]

@ram-mohan Thank you for adding support, the results look great.