Allow for larger excursions of min, max content boost #215
Conversation
|
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. |
|
@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! |
|
Besides, we may also try out #236, which has similar effects for API-1 in my local tests but it's much easier. |
Dichen, I have made the necessary changes and pushed a patchset. |
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. |
Current implementation clips min/max content boost to a smaller range. Allow for larger excursions for better hdr intent representation. This is not enabled by default and is enabled in best quality encoding preset. Test: ./ultrahdr_app <options> -D 1 Test: ./ultrahdr_unit_test
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