the future of histogram

[Bart Coppens]

On Thursday 11 August 2005 15:35, Casper Boemann wrote:
> I think that 256 bins would be enough in all cases, so I intend to do away
> with the bin iterator in the histogram class and just return an array of
> 256 bins.
> Anyone disagree?
I agree with you. For a 16 bit colorspace a user would have to have a screen 
of at least 65536 pixels wide to see the whole histogram, and then we don't 
even have a histogram of 32bit float... So I'd go with the 256 bins here, 
yes.

> Also I need to make it colorspace independent and make historag of each
> channel and also be able to calculate a histogram of things like intensity
> and hue. This is more difficult so if anyone has a brilliant idea..
> perhaps it should go into the colorspace or perhaps a simpler solution
> exists?
We definitely want other things than only the channels there. (The gimp has 
value and a 'composite' of R, G and B channel histograms.)
Also, I've noticed that the gimp does a much faster job at calculating the 
histograms... Maybe in fixing (part of) that, we could do something to this 
as well.

What if we would iterate the entire layer once. Then for each pixel we have, 
give it to different 'histograms'. We could have regular 'colorhistograms', 
that act like what we have now: they add the value of the channel they are 
associated with to their bucket. And we could have 'valuehistogram' taking 
the 8-bit value of the pixel and adding it to it's right bucket. Then when 
the user asks for, for example, the 'red' histogram we pick the right 
histogram and use its values. If he then asks for a hue histogram, we do the 
same with the associated histogram.

Also, I don't think we should be adding this to the colorspaces, they're 
bloated enough already. For example, the 'hue histogram' can just take 
toQColor of the pixels he gets, and then calculate the hue from that. I think 
that's allright because we'd only have a precision of 256 bins for each 
channel :-)

Bart Coppens

Bart Coppens