Suggestion: update the "-s" flag default to 1

[gregbenz]

The user is in control of gain map down sampling via the "-s" flag in the demo app. However, I recommend updating the default to 1 (vs the current 4) to ensure the default behavior is correct most of the time.

For images where quality is important or the resolution is low, a 1:1 sampling is required. A lower 1:2 sampling rate can be a reasonable choice to reduce file size in many cases, but quality will be degraded. The default 1:4 is almost never ideal as it will frequently cause quality problems in high frequency detail such as edges.

[cmahnke]

Well, I guess the current setting is due to the increased file size if there is no subsampling of the gainmap. Keep in mind that this code had more quite arbitrary looking limitations (like the max size) that were introduced by the primary use case of mobile phones.

Maybe it's an workable approach to consider profiles? Like photography which would set 1:1 sampling, (this one is made up) web with 1:2 and mobile with 1:4 (current default).
Additionally those profiles could also imply more settings:

profile	encoding preset (-D)	quality factor (-Q)
photo	1	100
mobile	0	85

[ram-mohan]

@cmahnke This comes down to how the library is handling the 420 subsampling format. The library supports input color formats UHDR_IMG_FMT_24bppYCbCrP010, UHDR_IMG_FMT_12bppYCbCr420. Both these formats have chroma planes subsampled by 2, horizontally and vertically. Each chroma pixel corresponds to 4 luma pixels. Library holds this attribute too tightly and evaluates chroma plane dimensions as half of luma plane dimensions (round_down(w / 2) and round_down(h/2)). It is possible to have 420 subsampled images with odd dimensions where the edge chroma pixels correspond to 1 or 2 luma pixels but this was not handled. Once the evaluations in the library are modified to (round_up(w / 2) and round_up(h/2)) in subsampling formats, this restriction can be lifted. For rgb inputs, this restriction should not be enforced. But we are in the process of adding support for odd dimensions for all formats, so no changes were made specific to rgb.

[cmahnke]

@gregbenz: You're right about naming, I totally agree.
Just for clarification, we are talking about the app here, aren't we? Since it certainly won't be used itself in the context of a mobile phone (instead a implementing library would use the library) primary target audiences are certainly professionals like you.

[cmahnke]

@ram-mohan: Thanks for pointing this out! Should we add the support of uneven dimensions to the issue tracker?

[gregbenz]

I'm thinking mostly of the app. But for either the app or library: I would suggest any default/recommended settings optimized for reasonably high quality, and any alternatives should be named for the encoding objective to ensure clarity as to which option set is best suited for a given use.

[ram-mohan]

@cmahnke yes please, thank you.

[ram-mohan]

The desired changes are merged to main. This can be marked as resolved.