Re: Logarithmic histogram

[Roel Schroeven]

  Linear, Log, and sqrt are all common ways to scale histograms for
display.
  Perhaps we should make it an option in preferences (or in the histogram
  display itself).

 sqrt() - I haddn't thought of that.  That sounds plausibly like what
 Photoshop is using.   I might have a play with that.

To me, it looks like Photoshop uses linear, but if there are some peaks that
are very high relative to the rest of the histogram, they don't show these
peaks completely (they are clipped off) in order to be able to show some
detail in the lower parts. I tried something similar in Gimp, and for a
number of images I tried, the histograms of Photoshop and the Gimp were very
similar.
If you want, I can post the code I used for it.
I'm not sure about how to determine the clipping, though; now I have done
something like (I don't have my code here with me) after the calculation of
max in the function that calculates the heights of all peaks (I forgot the
name)

avg = ...
if (max  avg * 4)
  max = avg * 4;

Note: the average is not the average as shown in the histogram widgt; it is
the average height of all peaks in the histogram which is something
completely different.

But perhaps it is better to use the median instead of the average, or maybe
the 90% percentile or something.

Roel Schroeven

Value in histogram

[Roel Schroeven]

The value in the gimp histogram is calculated as the maximum of the red,
green and blue channels now. Wouldn't it be better to use the average of the
three color channels?

Incorrect median value in histogram

[Roel Schroeven]

The median value in the histogram was not calculated correctly; here is 
a little patch to correct the error.

diff -ru ../old.gimp-1.2.1/app/gimphistogram.c ./app/gimphistogram.c
--- ../old.gimp-1.2.1/app/gimphistogram.c   Mon Feb  5 20:29:36 2001
+++ ./app/gimphistogram.c   Mon Feb  5 20:30:07 2001
@@ -473,7 +473,7 @@

  for (i = start; i = end; i++)
{
-  sum += i * histogram-values[channel][i];
+  sum += histogram-values[channel][i];

  if (sum * 2  count)
   return i;


Roel Schroeven

Re: incorrect mask handling in histogram calculation

[Roel Schroeven]

Austin Donnelly wrote:

 So, fixing this bug means that the Levels tool, the Threshold tool,
 and the Equalise tool will all also change their behaviour: currently
 they use a histogram of the entire layer, but restrict their changes
 to the current selection.  Fixing the bug means that the histogram
 will only be calculated for within the selection too.  Is this the
 desired behaviour?

If the other tools pass a null pointer for the mask, the histogram is still
calculated for the entire layer, so I think this shouldn't be a problem.

Logarithmic histogram

[Roel Schroeven]

I noticed in the source code that the histogram widget uses a logarithmic
scaling. Is there a reason to do it that way, as Photoshop et al. seem to
use a linear scaling.

Sorry if this has been brought up before; I searched in the mailing list
archives, but didn't find anything on it.

incorrect mask handling in histogram calculation

[Roel Schroeven]

I just downloaded (and installed and build) the 1.2.1. sources, and I 
was looking at the histogram code (because I wonder why the histogram 
always looks totally different than histograms from Photoshop or Paint 
Shop Pro) and I saw something (unrelated to what I was doing) that looks 
like a bug.

In gimphistogram.c there is a function to calculate the histogram for a 
subregion, declared as follows:

gimp_histogram_calculate_sub_region (GimpHistogram *histogram,
PixelRegion   *region,
PixelRegion   *mask)

In that function we have this code snippet:

  if (mask)
   {
 gdouble masked;

 src = region-data;
 msrc = region-data;

I would think that msrc ought to be a pointer into the mask data instead 
of the region data, like this:

   msrc = mask-data;


Regards,
Roel Schroeven