When doing subtle curve corrections to 16-bit images, the histogram often shows damage caused by the curves correction. The resulting histogram looks 'hairy' (see attachment), which suggests that the curve correction calculation is done at 16 bits per channel. This lack of precision causes many different input values to yield the same output value, which explains the spikes on the histogram. I have not seen any visible effects of the damage caused by the curves plugin, but it might be easy to fix: 1. Take the 16-bit input value, store in 32-bit variable. 2. Bitshift the 32-bit value to the left by 16 places 3. Add a random 16-bit value 4. Apply curves correction function, yields 32-bit output value 5. Bitshift the 32-bit output value to the right by 16 places 6. Store 32-bit output value in 16-bit variable The same applies to curve corrections to 8-bit images, which requires 16 bits of precision. Reproducible: Always
Created attachment 75295 [details] Hairy output histogram
I just bumped into an older report, Bug #170169, which is basically the same problem. The current work around for Bug #170169 is to convert the image to higher bit depth before performing the operation. For 16-bit images this is not an option, because there is no bit depth greater than 16 bits in DigiKam (CinePaint did have it if I remember correctly). Both problems *should* be fixed when 1. Operations on 8-bit images are always done in 16-bit precision 2. Operations on 16-bit images are always done in 32-bit precision This applies not only to curve correction, but to any operation on pixel values. Curve adjustment is very sensitive to precision though, which makes that the problem really shows in this plugin.
Merge both bugzilla files to an unique entry please... Gilles Caulier
Main entry for this problem is now Bug #170169. *** This bug has been marked as a duplicate of bug 170169 ***
Fixed with https://bugs.kde.org/show_bug.cgi?id=170169