Improve Gamma-Corrected Resizing with Higher Internal Bit Depth

Ideas for improvements and requests for new features in XnView MP

Moderators: helmut, XnTriq, xnview

Post Reply
stortKC48
Posts: 1
Joined: Thu Jul 31, 2025 8:51 am

Improve Gamma-Corrected Resizing with Higher Internal Bit Depth

Post by stortKC48 »

When resizing images with *“Use gamma correction”* enabled, dark areas still show visible posterization and banding. This issue has been reproducible across multiple versions of XnView MP (starting from 0.92), and I have confirmed that it still exists in the latest Windows version 1.9.2.

My own test comparisons are attached. Conversion was done from 3000×3000 to 2000×2000 using Lanczos2, with and without Gamma Correction:
4534530153593.7z
(626.12 KiB) Downloaded 716 times
The original figure can be found here.

Reference to the original bug report/discussion: 0.92: Downscaling with gamma correction posterizes dark areas

As pointed out in that thread, the problem is caused by low internal processing depth:
damian101 wrote: Thu Aug 29, 2024 11:25 am Internal bit depth needs to be higher, then this won't happen. Currently, it seems to be 8 bits per channel, which is a joke, awful banding everywhere in dark gradients. Linear light needs to be processed at 16 bits per channel (sufficient for this) or higher internally.
Suggestion
Please consider increasing the internal processing depth for gamma-corrected resizing. Using at least 16 bits per channel for calculations should eliminate most of the banding and preserve image quality much better.
dchristensen
Posts: 16
Joined: Sun Aug 11, 2024 5:37 pm

Re: Improve Gamma-Corrected Resizing with Higher Internal Bit Depth

Post by dchristensen »

I would like *all* operations that xnview does to be done with higher precision, and that the result of each operation be stored in memory with higher precision so that subsequent operations use the high precision output of the previous step. For example, if I use the curve tool twice, it can result in posterizing of the image, due to the rounding to 8 bits that is done after the first application of the tool.

To be clear, I'm asking that when a file is read, it be stored internally with more bits per channel. (User configurable? Or just 16 always?) Each operation would be done to this higher precision representation. Only when exporting to a file would the bit depth be reduced, and then only for the file on disk; the internal representation would retain the higher precision in case further operations are done.
Post Reply