# Histograms with non [0-256] values

Hi,

I know I

Hi Bob, thank you for responding all my posts :)

I still don´t know what value assign to nbins.

If I have image values of 8 bits, there is no problem: nbins = 256; 1 bin for each sample.

If I have float or double values, I can´t apply max-min+1 , because I need an integer number of bins, and also you are treating with very close decimal, and possibly negative values!!.

I have been observing the ENVI tool (sure you know it, it´s not related with Java), and it always gets the bin width such that there are no bins in histogram stadistics with value 0. Sometime it chooses nbins= 256, sometimes=177....

Which is the rule?

Also, for a 16 bit image, for example, when you talk about min and max extrema values, do you mean [0- 65536] range, or , for each band, [min value registered - max value registered] range?

Thank you very much!

There is no particular "rule"... it's a matter of what you need for your

application.

For float data, nbins is arbitrary... you can put in any number you

want. It's the usual tradeoff between speed and accuracy... more bins

gives you more precision in your histogram, but at the expense of more

computation time and memory usage (not that it adds much to the time for

a histogram unless you get ridiculously large).

So unless you have other constraints, just use 256. It's a nice, round

(in computer terms) number; you get decent resolution in the histogram

without having too many bins to work with.

I don't know why ENVI would bother trying to ensure there are no bins

with 0... that's overkill. But having a lot of 0 bins on one end or the

other (with counts all clustered in the middle) means you might want to

adjust the min/max to spread it out a bit. Setting min/max

appropriately is far more important than any particular value of nbins.

Here's a fundamental question: Why are you computing a histogram in the

first place? THAT is what should drive your choice for nbins.

Presumably it's for some kind of histogram equalization, in which case

256 is a decent choice, as long as the min/max are appropriate.

Oh, and yes, extrema means the data range actually seen in the data, not

the theoretical range possible in the data type.

Here's one way to set the min/max if you want to do multiple passes.

First, do a histogram using the actual extrema. Figure out the total

number of pixels (h*w). Start at one end of the histogram and move

toward the center, adding up the number of pixels you see in each bin.

Stop when you get to a threshold, say 5%, of the total number of pixels.

Whatever the bin value is when you reach the threshold, becomes your

min or max for the second iteration. It shouldn't take more than those

two iterations unless you have some pathological cases. Those limits

are also good candidates for the endpoints of a linear stretch.

Basically, you're saturating 5% of the pixels to pure white or pure

black, stretching out everything in between. The threshold should be an

adjustable parameter.

-Bob

jai-interest@javadesktop.org wrote:

> Hi Bob, thank you for responding all my posts :)

>

> I still don´t know what value assign to nbins.

>

> If I have image values of 8 bits, there is no problem: nbins = 256; 1 bin for each sample.

>

> If I have float or double values, I can´t apply max-min+1 , because I need an integer number of bins, and also you are treating with very close decimal, and possibly negative values!!.

>

> I have been observing the ENVI tool (sure you know it, it´s not related with Java), and it always gets the bin width such that there are no bins in histogram stadistics with value 0. Sometime it chooses nbins= 256, sometimes=177....

>

> Which is the rule?

>

> Also, for a 16 bit image, for example, when you talk about min and max extrema values, do you mean [0- 65536] range, or , for each band, [min value registered - max value registered] range?

>

> Thank you very much!

> [Message sent by forum member 'sportinguista']

>

> http://forums.java.net/jive/thread.jspa?messageID=478103

>

> ---------------------------------------------------------------------

> To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net

> For additional commands, e-mail: interest-help@jai.dev.java.net

>

---------------------------------------------------------------------

To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net

For additional commands, e-mail: interest-help@jai.dev.java.net

Thank you!

I´ll set 256 as a constant number of bins for float and double values. For byte, or integer (short, ushort, integer) I´ll set binwidth to 1, and number of bins (maxvalueregistered-minvalueregistered).

I don´t know why the output "histogram" always gives 0 for the last value... (I´m putting [] as () in some expressions for avoiding displaying restrictions)

int[] nbins = new int[nbands];

if ( ...my check if it´s byte, ushort, short or integer... )

for (int i = 0; i < nbands; i++) {

nbins(i)=(int) ((extrema(1)(i) - extrema(0)(i))+1);

}

else

for (int i = 0; i < nbands; i++) {

nbins(i)=256;

}

pb.add(nbins);

pb.add(extrema(0));

pb.add(extrema(1));

RenderedOp dummyImage = JAI.create("histogram", pb);

Despite this detail, all my "histogram functionality" works fine, so I won´t bother you anymore :P

Thank you again for your time!

Well it depends on what you want.

If you want a histogram that counts every pixel value independently,

then the nbins is just max-min+1 (where you get those from extrema, and

it's what you pass in to the operator, as in your example).

However, that realistically only works for short int data, where you

might have up to 65536 bins. That's not an unreasonable number. But if

you have full int data, you could have up to 4 billion bins... which

won't work well. And the concept is not even well defined for float or

double data.

For those (and often, even for short ints), you instead combine a range

of pixel values into a "bin" and count up all the pixels within that

range. So you could have as many (or as few) bins as you want; 256 is

often a good number even for non-byte data. If your data range is

0-1023 and you have 256 bins, then 4 different pixel values will be

counted together in each bin. For almost all uses of a histogram, this

is sufficient as long as the data range is appropriate (e.g. if your

float data has 1e+38 as a flag value, you'd want to omit that from the

maximum or the bins wouldn't make sense).

Bottom line is, I don't see any reason your code shouldn't work as-is;

you can set nbins to just about anything. Print out what the extrema

are to ensure they make sense.

Hope that helps...

-Bob

jai-interest@javadesktop.org wrote:

> Hi,

>

> I know I´m posting too much, but really need to finish my job and there is very little info (and such little is duplicated, triplicated...) in www.

>

> Reading this forum, I realize that it has not been talked too much of working with image data out of 8 bit range. [0-256]

>

> I´m now trying to create histograms with non byte data. There´s one thread asking for 16 bit images histogram, but the solution doesn´t seem to work.

>

> Well, I am following this model:

>

> https://jaistuff.dev.java.net/code/display.DisplayHistogram.java

>

> but when I try to manage histograms with 16bit ( >8bit in general ), float, or double typed images, there is no information in google, neither java.net forum.

>

> So, has anybody worked with histograms with non byte values?

>

> If don´t, Could any JAI developer publish an example, please?

>

> How can this code be modifyed in order to be adapted to non-byte values?

>

> RenderedOp op = JAI.create("extrema", pi); //pi -> PlanarImage

> double[][] extrema = (double[][]) op.getProperty("extrema");

>

> ParameterBlock pb = new ParameterBlock();

> pb.addSource(pi);

> pb.add(null);

> pb.add(1);

> pb.add(1);

> pb.add(new int[]{nbins}); // how can I calculate 'nbins' if it is not TYPE_BYTE? nbins != 256

> pb.add(extrema[0]); // Is it correct this?

> pb.add(extrema[1]); // and this?

> RenderedOp dummyImage = JAI.create("histogram", pb);

>

>

> Thank you all again, I don´t know anywhere else to ask.

> [Message sent by forum member 'sportinguista']

>

> http://forums.java.net/jive/thread.jspa?messageID=477981

>

> ---------------------------------------------------------------------

> To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net

> For additional commands, e-mail: interest-help@jai.dev.java.net

>

---------------------------------------------------------------------

To unsubscribe, e-mail: interest-unsubscribe@jai.dev.java.net

For additional commands, e-mail: interest-help@jai.dev.java.net