| Summary: | Curves adjustment requires higher bit depth | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Dik Takken <kde> |
| Component: | Plugin-Editor-Curves | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | caulier.gilles, knizek |
| Priority: | NOR | ||
| Version: | 0.9.4 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 7.5.0 | |
| Sentry Crash Report: | |||
| Attachments: |
Example of histogram "before"
Example of histogram "after" |
||
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 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 ImageMagick doesn't damage histogram when making such adjustments. Mik, How are tested that. can you give me an ex. Gilles Created attachment 27182 [details]
Example of histogram "before"
This is an original image.
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
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 No, I don't see improvement by going 8-16-8. (0.10-beta7svn) 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. Dik, With digiKam 2.x, 8 to 16 bits alogirthm add noise to fill histogram holes. Please try again with this version Gilles Caulier 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. *** Bug 310211 has been marked as a duplicate of this bug. *** Changed title to reflect the more generic problem described in both this report and in Bug #310211. 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 |
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.