different histogram in labview and matlab.

[labmaster]

The png format image contained the data. Therefore, the absolute value of each pixel is important to be preserved.

During analyzing images, I found there is a spike noise(1.png in attachement).

It can be represented in almost dark color in an image viewer.

But, I got to know the 1.png contained data.

In comparing 2.png, I got to know the similar data in histogram function in Labview.

But, I can't understand why the matlab or intensity viewer in other programs represent the image so differently.

See the attachement, histogram of1.png in labview vision and matlab using "imhist()" function

.

I believe labview's histogram is more suitable to our purpose.

What's the different thing between two languages?

labmaster.

*)i attach test images and LV code for NI-Vison. 

Message Edited by labmaster on 07-08-2009 05:01 PM

Message Edited by labmaster on 07-08-2009 05:04 PM

[SMeserve]

Hi labmaster,

I noticed that the ranges on the two histograms are totally different.  This might affect the binning of the histograms and affect the data you are seeing.  Additionally, there may be differences in the way the histogram data is calculated and this would certainly affect the way the data is displayed.

[labmaster]

Thanks,

I would like to change my interest.

I got to know the histogram of Labview is unsuitable to my purpose.

Labview save the data to an image relatively. 

I confirmed this by several kinds of 3rd party viewer program and matlab using unsigned 16 bit integer.

The attachment demonstrate it.

Labview seems to convert the data to relative quantities in the image.

As you can see the original image (2D array in vi) has the numbers around few thousand integers.

But, in saving to png or other format image, the data is converted to relative scale.

As I mentioned, my data pixels are real data in range of U16 in this posting. 

Therefore, I would like to ask NI field engineer or others differently.

"How to express my data in image format absolutely not relatively?"

I have tried the color palette one time. but I can't control the color palette in saving the image in U16 or I16 data.

Best,

Labmaster.

Message Edited by labmaster on 07-09-2009 05:16 PM

Message Edited by labmaster on 07-09-2009 05:17 PM

[labmaster]

I found my problem is happened because of PNG file.

Tif I16 file has no problem.

Is it bug in PNG or special behavior in PNG?

labmaster.

[labmaster]

For your understanding, I attached the histogram of PNG and TIFF.

TIFF is right but PNG was saved incorrectly in each pixel ABSOLUTE value.

Does anyone NI-Vision engineer recognize this strange behavior in VISON Development suite?

Labmaster

Message Edited by labmaster on 07-14-2009 05:15 PM

[Vivek_N]

Hello,

I ran your 'histogram_2.vi' to create a new PNG file, and then ran the 'histogram.vi' and was able to successfully see the correct values show up. Please see the attached screenshot. So, it does seem to work on my PC.

However, I did notice the unexpected histograph when I ran the histogram.vi for images '1.png' and '2.png'. How exactly were these image files created? It may have something to do with how those images were saved. Also, what version of the Vision Development Module are you using?

[labmaster]

Thanks,

I am trying to contact NI for this problem.

The image array was created from DAQmx I16 function.

As you mentioned, I also found some small I16 array didn't show this problem.

My data contains 250*250 (sometimes, 500*500) elements.

Vison (8.6, commercial version) and LV 8.6.

labmaster.

[labmaster]

I forgot something.

Please try again with any 3rd-party program(matlab, photoshop, etc) to check the real histogram.

When I read the png file to array (image to array.), the raw data was shown correctly.

Maybe, this is related to Labview's histogram function, so you could see the right histogram.

We got to know this problem in analyzing data.

Labmaster.

*)Currently, I am using tif format although NI recommend to use PNG format.

Message Edited by labmaster on 07-16-2009 09:12 AM

Message Edited by labmaster on 07-16-2009 09:13 AM

[AnthonV]

I am no expert but the PNG standard requires that when saving to PNG, the data is scaled to the next higher bit depth that is supported by PNG.  In other words, if you are using a 12-bit image, when saving to PNG it has to save to 16bits and it then scales the data.  But you would think that it scales it by 4 bits - no - it uses the dynamic range of the image that you are saving.  So if your image's largest pixel value fits into 10 bits (say the value 987), than it will scale the whole image by 6 bits to fill the full 16 bit range.

This is described in http://www.libpng.org/pub/png/spec/1.2/PNG-Encoders.html quite well.

So if you are reading your PNG image (that you saved in LabVIEW), the maximum pixel value will now be close to 63168, instead of 987 as you expected.  (I'm saying 'close' as the scaling also includes some 'left bit replication' which doesn't simply leave the least significant bits at zero as a straight-forward left-shift would).

You saw the same effect where the maximum value of the histogram was 6372, but after saving to PNG and reading with a 3-rd party viewer, the maximum value was 50982, meaning a shift of 3 bits with left-bit-replication resulting in a ratio of 8.0009).

However, if you read the PNG file again in LabVIEW - the maximum value is again reported as 987!  So somehow LabVIEW reads the original scaling information from the PNG file and downshifts, while Matlab doesn't.  

Can anyone tell me how to get Matlab or other viewers to also read this original scaling info or how to get LabVIEW to stop scaling and save the PNG raw?

[labmaster]

I used the full signed I16 data type.

As I mentioned above, some small array doesn't show this problem (of course 16 bit).

Anyway, I don't believe NI make the library to do so intentionally.

I know the scaling information. 

PNG vi has no option of the useful scaling information.

The vi has an option to select the bit depth but useless.

I guess current NI PNG vi is not in good state.

labmaster.