different histogram in labview and matlab.

[AnthonV]

---

labmaster wrote:

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.

---

See even if the original data is 16bit, if the maximum value of all the pixels can be represented by fewer bits (as in my example above where a 16bit value of 987 can fit into 10 bits), a PNG encoder may scale the pixels that it fills the full 16 bits (ie the 16th and most significant bit is always 1).

From what I understand from the spec, this is an optional feature that PNG encoders may or may not implement. 

[AnthonV]

I've read the spec again and I think that you might be correct re a bug in LabVIEW's PNG write function.  It should only be scaling the data if it is represented by a datatype (say U12) that cannot be represented by PNG (in this case U16 is the next best and the data will be scaled up).  

But in LabVIEW's case, the data is already U16 (in my case I'm using RGB64) as it only has 16bit or 8bit image types, so no scaling should ever be done.  If you are saving these images to read them later using LabVIEW, it doesn't seem to be a problem as it rescales it to the original values, but if you read these PNG's using say Matlab, you've lost the absolute amplitude of your image.  This is a big issue when you are trying to calibrate a camera's gain offline for instance.

Maybe somebody on this inside could comment on this?  

[Albert.Geven]

Hi

We experienced the same as you in using png in LabVIEW and matlab, but I came to another conclusion:

Matlab is wrong in reading the scaled png files. LabVIEW is correct.

It is a waste of calculation to scale when the databits fit but it is correct.

We now use a simple binary format for communicating with matlab.

[labmaster]

I don't think so.

I verified this other 3rd party program as well as Matlab.

I believe Labview code is incorrect.

How can you explain the different result with Tiff?

labmaster.

Message Edited by labmaster on 07-21-2009 06:56 PM

[AnthonV]

Here is another example of where the evidence seem to indicate that 8.6.1 does not save PNG's correctly.  I was displaying a 12-bit image (RGB64) using the image display control.  This is what it looks like on the front panel:

I then saved the image by right-clicking on the image and clicking 'save as' and typing a filename ending in .tiff.  Viewing it results in the following (after adjusting the viewer's brightness as the image now only fills part of the 16-bits of the tiff image):

Using the same procedure (right-clicking the image on the front panel) I saved the image as a .png and when viewing the png file the following can be seen (this is verified by using Matlab, ACDSee and other viewers):

There is something strange happening when LabVIEW is saving png images.

Any comments?

[labmaster]

Thank you, AnthonV.

I have no idea if your 12bit data problem is related to mine. 

I reported my problem (16bit data representation) to the NI support team.

They kindly agree to me about this problem. 

I believe this can be shooted in future update.

Sungjun 

[AnthonV]

Hi, this is still happening in 2009.  I think I need to log this officially as a bug - what is the official way of doing this?

[labmaster]

Yesterday, I check if my claim is solved in 2009 version.

But, I can't find the CAR ID of "181735" in bug fixed list.

I think so many users with png format didn't recognize this problem.

Anyway, you can check with CAR ID in future. 

labmaster.

Message Edited by labmaster on 10-30-2009 08:16 AM

[AnthonV]

Yes thanks I will check this CAR - but could you send me a link to where one would check on the status of a CAR?

[labmaster]

http://www.ni.com/support/lv2009.htm

Please refer "list of bug fixes".

You can find the list of CAR ID.