search

google / libultrahdr

Ultra HDR is a true HDR image format, and is backcompatible. libultrahdr is the reference codec for the Ultra HDR format. The codecs that support the format can render the HDR intent of the image on HDR displays; other codecs can still decode and display the SDR intent of the image.
https://developer.android.com/guide/topics/media/platform/hdr-image-format
Apache License 2.0
146 stars 23 forks source link

Allow for larger excursions of min, max content boost #215

Closed ram-mohan closed 3 weeks ago

ram-mohan commented 1 month ago

Current implementation clips min/max content boost to a smaller range. Allow for larger excursions for better hdr intent representation.

Also, fixed round factor before encoding gainmap coefficient

Test: ./ultrahdr_unit_test

DichenZhang1 commented 1 month ago

We may not be able to merge this since this may introduce other concerns (e.g. performance drag, introducing error if the input is compressed due to compression artifacts). Besides, existing components e.g. Skia is using the old logic, and moving to this logic may lead to changes outside this library. We can hold this for now.

DichenZhang1 commented 1 month ago

@ram-mohan @harishdm we will take this change, and some modifications need to be done.

We can introduce an encode mode parameter, "SPEED" mode and "QUALITY" mode, the former to be default. Under "QUALITY" mode we do this. This can happen in API-1, 2, 3 (no API-0 because our internal tone mapping already considered this)

I suggest in this change we start with a macro definition of the encode mode parameter, and making it configurable through the command line app in a follow-up change.

Thank you for your help!

DichenZhang1 commented 1 month ago

Besides, we may also try out https://github.com/google/libultrahdr/pull/236, which has similar effects for API-1 in my local tests but it's much easier.

ram-mohan commented 1 month ago

@ram-mohan @harishdm we will take this change, and some modifications need to be done.

We can introduce an encode mode parameter, "SPEED" mode and "QUALITY" mode, the former to be default. Under "QUALITY" mode we do this. This can happen in API-1, 2, 3 (no API-0 because our internal tone mapping already considered this)

I suggest in this change we start with a macro definition of the encode mode parameter, and making it configurable through the command line app in a follow-up change.

Thank you for your help!

Dichen, I have made the necessary changes and pushed a patchset.

ram-mohan commented 1 month ago

Besides, we may also try out #236, which has similar effects for API-1 in my local tests but it's much easier.

This should improve quality but solution is not universal. Even though the lower limit is extended from 0 to -6.64, to some extent it is clamped and the upper limit is still clamped. Range of content boost is indicative of dynamic range of recovery of hdr intent from sdr intent. Clamping to a predefined value can work in most cases, but there can be scenarios where this can cause limitations.

DichenZhang1 commented 1 month ago

Thank you for the latest change. My point is if #236 can give us similar quality improvement as this one, we can consider taking #236. Or we may take both.