Bug 144155 - wrong(?) histogram y-axis when blown-out over/underexposure
Summary: wrong(?) histogram y-axis when blown-out over/underexposure
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Unclassified
Component: ImageEditor-Core (show other bugs)
Version: 0.9.2
Platform: Compiled Sources Linux
: NOR normal with 1 vote (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-12 21:22 UTC by lparrab
Modified: 2022-02-03 11:07 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 1.0.0


Attachments
histogram for a picture with blown-out highlights (148.52 KB, image/jpeg)
2007-04-12 21:24 UTC, lparrab
Details
LIGHTROOM: histogram for a picture with blown-out highlights (156.39 KB, image/jpeg)
2007-04-12 21:29 UTC, lparrab
Details
PATCH: limit the Y-axis of image histogram to 3*(90-percentil) (7.91 KB, patch)
2007-04-13 03:50 UTC, lparrab
Details
screenshot of the patch for limiting the y-axis based on percentiles (161.21 KB, image/jpeg)
2007-04-13 03:56 UTC, lparrab
Details
PATCH: limit the Y-axis of image histogram to 3*(90-percentil) (9.31 KB, patch)
2007-04-13 23:51 UTC, lparrab
Details
histogram example (35.93 KB, image/png)
2007-04-18 18:20 UTC, Arnd Baecker
Details
example images and their histograms (251.61 KB, image/png)
2007-06-13 17:46 UTC, Arnd Baecker
Details
PATCH max calculation with cutoff over/underexposure (7.60 KB, application/octet-stream)
2009-11-30 23:17 UTC, Jens Mueller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lparrab 2007-04-12 21:22:41 UTC
Version:           9.2 (svn 2007-04-17) (using KDE KDE 3.5.6)
Installed from:    Compiled From Sources
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.20-6-generic

for images with a certain degree of over/underexposure (clipping/blown-out) the histogram in digikam becomes useless because the y-axis seems to be scaled to accommodate the blown-out highlights or shadows, making the scale for the rest of the picture way to big.

the y-axis should be scaled so that (example) 50% of "Y" represents the highest peak of the non-clipped pixels, effectively cutting the top of the y-axis.
Comment 1 lparrab 2007-04-12 21:24:56 UTC
Created attachment 20254 [details]
histogram for a picture with blown-out highlights

take a look at the histogram: due to the blown-out parts, the y-scale is waaaay
to big for the rest of the histogram, effectively making it useless.
Comment 2 lparrab 2007-04-12 21:29:17 UTC
Created attachment 20255 [details]
LIGHTROOM: histogram for a picture with blown-out highlights 

this is lightroom showing the same picture as digikam in the first attachment.
you can still see that the highlights are being clipped, but the rest of the
histogram still has a recognizable form.

in digikam you would have to use logarithmic scale to see anything --but that's
not intuitive for photography work.
Comment 3 caulier.gilles 2007-04-12 21:32:15 UTC
>in digikam you would have to use logarithmic scale to see anything --but that's
>not intuitive for photography work. 

Why it's not intuitive ? It work perfectly...

Gilles caulier
Comment 4 Arnd Baecker 2007-04-13 00:50:04 UTC
> >in digikam you would have to use logarithmic scale to see anything --but that's
> >not intuitive for photography work.
>
> Why it's not intuitive ? It work perfectly...


Well, while it works perfectly, there are many people
who are not familiar with logarithmic representations ;-)

So the histogram y-axis is surely not wrong
for over/underexposure, cutting off the upper part
of the histogramm looks like a good solution.

But how to determine the cut-off value?
Maybe
  cut_off = min( maximal_value_of_histogram, 2*vertical_variance)
or one determines the cut-off as
the largest maximum on the interval [0.1, 0.9] ?
Comment 5 lparrab 2007-04-13 03:47:11 UTC
yes, the logarithmic histogram does work perfectly: the calculation and the curve are "correct"...

however, I think that logarithmic scale is great for some physics or math graphs.. but in photography, a logarithmic histogram does not tell (at least not to me, specially not at the first blick) the proportion of the color distribution in the image

Since the problem is normally on the extrem left or right of the histogram, you could simply cut off the 1% of either side (not really cut, but don't take into account for the Y-axis)

Other approach would be to use a given percentil to set the limit. 
I'm attaching an example-patch to the current SVN version (anonsvs) which ensures that 90% of the pixels take at least some 33% of the Y-scale.

The 90% and 33% are arbitrary values and you could play a bit with them, but they seem to give a nice result.
I'm also attaching a screenshot of digikam with(svn) and without the patch(0.9)

regards. Luis
Comment 6 lparrab 2007-04-13 03:50:53 UTC
Created attachment 20257 [details]
PATCH: limit the Y-axis of image histogram to 3*(90-percentil)

like I said, the limits are really arbitrary, but work for me.

I changed the "getMaximum" function in imagehistogram.cpp to cache the
results.. but that is really not relevant. only the "getPercentil" and the
changes in histogramwidget.cpp are interesting.
Comment 7 lparrab 2007-04-13 03:56:30 UTC
Created attachment 20258 [details]
screenshot of the patch for limiting the y-axis based on percentiles

Digikam standard and patched versions showing the same image...

I think you can read much more information from the histogram in the
patched-version.
Comment 8 Arnd Baecker 2007-04-13 08:46:56 UTC
> I think you can read much more information from the histogram in the
> patched-version.


Full agreement - very nice!
(Haven't tried the patch yet, but the result looks really good to me...)
Comment 9 Gerhard Kulzer 2007-04-13 12:40:27 UTC
Am Friday 13 April 2007 schrieb lparrab@gmx.net:
[bugs.kde.org quoted mail]

I think the contrary is true, in photography you __always__ use logarithmic 
representation because it corresponds more to the subjective impression 
called "Lightness". The actual subjective law is a 1/3 power law 
(http://www.poynton.com/notes/colour_and_gamma/GammaFAQ.html#lightness). 

So if we want to improve the histogram I think the best would be (because it 
corresponds to our visual perception) to represent the histogram as a power 
law, and neither log nor linear, cupped or otherwise.

My 2
Comment 10 lparrab 2007-04-13 23:44:48 UTC
human perception/sensitivity to light is roughly logarithmic, yes. but I still find it easier(faster) to read a linear histogram that a logarithmic one.

If you really want to use the perception, then maybe(??) a histogram-graph is not the right tool, and some other kind of representation would be better...

Luis
Comment 11 lparrab 2007-04-13 23:46:47 UTC
Comment on attachment 20257 [details]
PATCH: limit the Y-axis of image histogram to 3*(90-percentil)

PATCH OBSOLETE
Comment 12 lparrab 2007-04-13 23:51:29 UTC
Created attachment 20267 [details]
PATCH: limit the Y-axis of image histogram to 3*(90-percentil)

The first patch had a bug: it broke logarithmic scale (not on purpose, really
=)

This patch cleans up the code a bit and implements my proposed
percentile-solution.
Comment 13 Arnd Baecker 2007-04-18 18:20:33 UTC
Created attachment 20315 [details]
histogram example

When trying to test this patch I realized, that it has already been applied
to svn, right?

Attached is an example of an image
with a large blown-out region, for which
I am not sure, whether the algorithm works so well,
i.e., wouldn't a much smaller vertical range be better?

On the other hand, for cases where it works
well, it might be good to leave a little bit
of vertical space so that the largest peaks
don't touch the upper edge of the histogramm.
Comment 14 Arnd Baecker 2007-06-12 21:32:08 UTC
Apart from my last comment - shouldn't this one be closed?
Comment 15 caulier.gilles 2007-06-12 21:34:49 UTC
Arnd,

Nothing have been applied on svn...

Gilles
Comment 16 Arnd Baecker 2007-06-13 13:11:44 UTC
Of course, Gilles, nothing has been applied to svn (somehow
I must have screwed that up last time I tried ...)
Comment 17 Arnd Baecker 2007-06-13 17:46:52 UTC
Created attachment 20849 [details]
example images and their histograms

I did a more thorough check of the patch, and find quite
a few cases, where it does not work optimally:
(A) too much is cut-off
(B) not enough is cut-off to the right
(C) too much is cut-off
(D) too much is cut-off

Maybe one should only use the largest 10% and lowest 10%
to detect blown out high-lights and shadows and
regard everything else as normal contents?

Unless there are any values which are being clipped, I would
suggest to always leave 2-3% of the height just blank,
so that it is clear, when something is clipped.

If you revise the patch, I am perfectly happy to test it again
(maybe we can still sneak it into the release candidate for 0.9.2 ;-)
Comment 18 Arnd Baecker 2007-07-06 08:43:05 UTC
Hi Luis,

did you have time to see whether it is possible to improve
the histograms for the examples I attached?

I think your patch is an important improvement, which maybe
can be improved even further! I am very eager if this could be 
be finalized in time for integration into 0.9.3.

Many thanks,

Arnd
Comment 19 Arnd Baecker 2007-11-05 09:57:50 UTC
Hi Luis,

any update on your patch (I'd really like if this could integrated in 0.9.3)?

Best, Arnd
Comment 20 lparrab 2007-11-06 23:51:39 UTC
Hello arnd

well.. the patch was  more or less working already.
the histogram is not 100% perfect for all images, but the results are IMVHO 
much better than the current implementation.

I havn't looked at it since then, and to be honest, I don't think I will find 
the time to do it anytime soon. so unless someone picks it up and finishes it 
(or merges it in its current state) it won't be in 0.9.3

I will probably give it another try if there are no volunteers, but like I 
said, it won't be anytime soon, sorry.

cheers. 
luis




On Monday 05 November 2007 09:57:52 Arnd Baecker wrote:
[bugs.kde.org quoted mail]
Comment 21 Arnd Baecker 2007-11-07 07:49:16 UTC
Hi Luis,

thanks a lot for the feedback!
The problem I see at the moment with the patch is that there
are cases where it does not work well enough in my opinion
(see the examples under #17).
It is clearly an improvement, but to me it is
not obvious wether the patch can be easily improved to 
always get it right, or not.
In my opinion it does not make sense to check in
some code for which it is not clear whether this
is the final solution, or if everything has to be ripped out
again later to make space for the real solution (tm) ;-).

Currently I am pretty busy with a long list of other issues,
so if you manage to have a look for an easy solution (e.g is some parameter tuning?), that's fine, otherwise this one will have to wait for a while.

Don't get me wrong: this is  a perfect example of an important contribution
to digikam to solve an issue, nicely illustrated with example images,
and a patch which improves things. So sooner (hopefully;-) or later 
this will get into svn.
(And: please keep your patches coming - contributions are very welcome!)

Thanks a lot, 

Arnd


Comment 22 caulier.gilles 2007-11-07 07:58:21 UTC
I second Arnd here. 

This file is a good example of contribution to an open source project...

Gilles
Comment 23 Marcel Wiesweg 2009-08-03 23:32:05 UTC
Activity here ceased long ago but it's still open and valid, as I found working with some images showing the problem.
It seems the approach taken by the patch cuts off too much if there is a high, but real peak (because it cuts off 10% in any case) and cuts off not enough if the image is severly overexposed (more than 10% overexposed).

If we can't find the perfect technique we should not apply it to the (strictly) linear histogram mode but maybe introduce a third drawing mode?

Some thought on this:
- this is mostly about under- or overexposure creating artificial single-line peaks because the natural distribution is cut. Is there a natural image situation where a peak in the middle of the scale need to be cut?
- restricting to the upper and lower limit, it would be possible to first find the minimum and maximum (usually at 0 and 255), see if one of these takes more than e.g. 5% (*) of the pixels. We could additionally check if the mean is greater (overexposed) or less than (underexposed) the median (*). The amount of cutting depends on the maximum value of the remaining segments. I am currently not sure how far the following segments (255: 254, 253,...) need to be examined as well.

(*) needs empirical investigation
Comment 24 caulier.gilles 2009-08-15 11:16:02 UTC
Marcel,

I'm agree to introduce a 3rd option to cut-off to 5% up/down histogram in high/low light.

Gilles Caulier
Comment 25 Jens Mueller 2009-11-30 23:17:11 UTC
Created attachment 38729 [details]
PATCH max calculation with cutoff over/underexposure

in case of overexposure or underexposure we do want cut these values but not the peaks at the midvalues (if there are any). So my patch does a max calculation between 0.1 and 0.9 and a max calculation for 0.0 to 1.0. The returned max is the minimum between both. The cutoff max can also only get a visual high of 0.8 here. 

So if we have no over/underexposure (no peaks at both ends of the diagram) the overall max is returned, if there are peaks at the end the max between 0.1 and 0.9 is retuned lowered by 0.8 to show the cutoffs.

The patch also takes care that the max value do not hit the upper diagram frame with a cutoff of 0.05.

The patch and especially the mystic values 0.1, 0.9 and 0.8 are up for discussion. Please give it a try.
Comment 26 caulier.gilles 2009-11-30 23:49:46 UTC
For me you rpatch work perfectly. With my all RAW files, when histogram is in linear mode, all is fine now. before, using log scale been necessary to show a suitable histogram. 

Arnd, lparrat, can you take a look ?

Gilles Caulier
Comment 27 caulier.gilles 2009-12-01 10:44:01 UTC
SVN commit 1056933 by cgilles:

Apply patch from Jens Mueller about to adapt histogram scale when image is over/under exposed.
Sound like a good way to display a suitable histogram in this situation
BUGS: 144155


 M  +8 -7      histogram/imagehistogram.cpp  
 M  +1 -1      histogram/imagehistogram.h  
 M  +52 -22    widgets/common/histogrampainter.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1056933