Bug 170169 - Curves adjustment requires higher bit depth
Summary: Curves adjustment requires higher bit depth
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Editor-Curves (show other bugs)
Version: 0.9.4
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-01 11:10 UTC by Dik Takken
Modified: 2022-01-15 12:46 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0
Sentry Crash Report:


Attachments
Example of histogram "before" (163.34 KB, image/jpeg)
2008-09-01 23:49 UTC, Mikolaj Machowski
Details
Example of histogram "after" (192.35 KB, image/jpeg)
2008-09-01 23:55 UTC, Mikolaj Machowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dik Takken 2008-09-01 11:10:32 UTC
Version:           0.9.4 (using KDE 3.5.9)
OS:                Linux
Installed from:    Gentoo Packages

When doing curve adjustment on 8-bit images, the histogram will get damaged pretty quickly: Holes appear, which leads to banding effects.

This problem might be fixable by doing the calculation in 16-bit and using noise. Let me explain. 

When converting an 8-bit image to 16-bit, the 16-bit image will still have 256 discrete brightness levels. So, the histogram of the 16-bit image looks like uniformly distributed spikes, placed (2^16)/256 = 256 apart. 

By adding noise with an amplitude of 256, the 16-bit histogram will become continuous: The spaces between spikes are gone. Applying a curve will yield a relatively smooth histogram, which can be converted back to 8-bit.

In pseudo C code, applying a curve to a 8-bit brightness value looks like this:

INT8 Curve8(INT8 inputvalue)
{
value16bit = ((INT16)(inputvalue)) + Random() - 128;

return (INT8)(Curve16(value16bit));
}

Where Random() is a random value between 0 and 255 and Curve16() is the 16-bit version of the adjust curves algorithm. Some bounds checking should be added to make sure the addition and subtraction will not yield funny results near the black and white ends of the scale.

At least the above technique allows the user to choose between banding and noise. The technique might also be useful in other plugins that tend to tear 8-bit histograms apart.
Comment 1 caulier.gilles 2008-09-01 11:27:01 UTC
Dik,

Sound like this feature:

http://www.powerretouche.com/Histogram_Repair_plugin_tutorial.htm

I have tried to find an algorithm to perform hiistogram repair, but time missing (:=))

Gilles Caulier
Comment 2 Dik Takken 2008-09-01 11:52:36 UTC
Hehe, yes, this looks like the same thing. Too bad they won't say how their magical repair tool works.. Hmm, wait.. I think I can guess... :D

I had no idea that even a simple plugin/algorithm like this can be used to make money... :D
Comment 3 Mikolaj Machowski 2008-09-01 19:59:04 UTC
ImageMagick doesn't damage histogram when making such adjustments.
Comment 4 caulier.gilles 2008-09-01 20:09:43 UTC
Mik,

How are tested that. can you give me an ex.

Gilles
Comment 5 Mikolaj Machowski 2008-09-01 23:49:44 UTC
Created attachment 27182 [details]
Example of histogram "before"

This is an original image.
Comment 6 Mikolaj Machowski 2008-09-01 23:55:52 UTC
Created attachment 27183 [details]
Example of histogram "after"

This image was created with IM command:
convert hist-before.jpg -contrast-stretch 0 hist-after.jpg
Comment 7 caulier.gilles 2008-12-06 18:31:07 UTC
Mik,

ImageMagick always use 16 bits color depth internally to process image correction.

I think than 8 bits image is converted to 16 bits, processed, and downgraded to 8 bits. 

Can you check if this workflow solve the problem here ? (You can change color depth in editor 8->16 and 16->8)

Gilles Caulier

Comment 8 Mikolaj Machowski 2008-12-06 21:58:23 UTC
No, I don't see improvement by going 8-16-8. (0.10-beta7svn)
Comment 9 Dik Takken 2008-12-15 10:16:46 UTC
Just converting an image from 8-bit to 16-bit will not work. The reason is that you will get a histogram with holes in it. Not really an improvement. The holes have to be fixed first, by blurring the histogram. Adding noise to the image will do exactly that.
Comment 10 caulier.gilles 2011-12-17 19:12:27 UTC
Dik,

With digiKam 2.x, 8 to 16 bits alogirthm add noise to fill histogram holes. Please try again with this version

Gilles Caulier
Comment 11 Dik Takken 2012-11-16 14:24:29 UTC
Tested on 2.6.0, and it works beautifully if you 

1. Convert to 16-bit depth
2. Apply curves
3. Convert back to 8-bit

This yields a smooth output histogram. Maybe it would be nice to do this conversion in the curves adjustment function itself, that would yield high quality curve adjustments out of the box.

See also bug #310211 which suggests a solution for the same problem, for 16-bit images.
Comment 12 Dik Takken 2012-11-18 12:49:19 UTC
*** Bug 310211 has been marked as a duplicate of this bug. ***
Comment 13 Dik Takken 2012-11-18 12:52:35 UTC
Changed title to reflect the more generic problem described in both this report and in Bug #310211.
Comment 14 caulier.gilles 2022-01-15 12:46:26 UTC
The problem can be easily fixed. Since a while now, digiKam image editor is able to convert a 8 bits image to 16 bits, adding noise.

Just apply this change before to play with curves.

I close this file now.

Gilles Caulier