Vision 6.1 gives unsigned integer .png files

[morgan]

I had Vision 6.0 on one computer and then moved my IMAQ board and Cohu CCD camera over to a computer that has Vision 6.1 on it. The images saved on 6.0 were fine when I read them into other applications (I'm using IDL to analyze the images). When I save the .png files with version 6.1, it looks like they are saved as unisigned integers, which nothing else seems to be able to interpret, including the copy of Vision 6.0. Is there a way to save the images properly with 6.1?

[cld]

Morgan,
We tried opening a 6.1 saved png with 6.0 and it worked fine. There are no reports of problems. However, if you are trying to read an save files that are greater than 8 bits, you want to keep in mind that there is no standard data format, so most other viewers including Internet Explorer only display the first 8bits of data and truncate the rest. This will display data stating at the most significant bit, but since we consider all 16 bits in processing, we store all of our data from the least significant bit up. Therefore, you may only be viewing the upper few bits. For instance if we stored 0000111111111111 for a 12 bit pixel, the Internet Explorer would only display 00001111 in the image, which will not map properly. You would want to bit shift the data the n
eeded number of bit. In this case 4 bits to display 11111111. I hope this helps.
Best Regards,
Chris D

[morgan]

thanks for the response Chris,
Was the way you saved .png files changed between 6.0 & 6.1? Because the 10 bit files we saved under 6.0 were read with no problems (just had to swap the byte order), whereas the ones saved in 6.1 cannot be read by other viewers.

We are now saving our 10 bit images as fits files using a vi, so we have circumvented the problem. But we do have a days worth of data in the vision 6.1 saved .png format that we haven't been able to read. Is there a reference to how .png files are saved somewhere so I can figure out how to strip out the bits I need?

thanks,
--morgan

[cld]

Morgan,
I am not aware of any changes, but I am also checking into this. However, I have attached an example I wrote to bit shift 12 bit images for external viewers and resave the images. For 10 bit images, just change the 4 bit shift to 6 and this should work.
Best Regards,
Chris D

[Glenn Randers-Pehrson]

cld wrote in message news:<506500000005000000DF960000-1027480788000@exchange.ni.com>...
> Morgan,
> We tried opening a 6.1 saved png with 6.0 and it worked fine. There
> are no reports of problems. However, if you are trying to read an
> save files that are greater than 8 bits, you want to keep in mind that
> there is no standard data format, so most other viewers including
> Internet Explorer only display the first 8bits of data and truncate
> the rest.

There *is* a standard format. The PNG specification requires such data
to be scaled up to fill the range. If you are displaying on 8-bit
hardware and have a 16-bit file you are allowed to throw away enough
low bits to fit your hardware.

>This will display data stating at the most
significant bit,
> but since we consider all 16 bits in processing, we store all of our
> data from the least significant bit up. Therefore, you may only be
> viewing the upper few bits. For instance if we stored
> 0000111111111111 for a 12 bit pixel, the Internet Explorer would only
> display 00001111 in the image,

That's correct behavior, if the display can only handle 8 bits.

> which will not map properly. You would
> want to bit shift the data the needed number of bit. In this case 4
> bits to display 11111111.

You are supposed to do that before storing the data in the PNG file.
You can fill the remaining bits by Left-bit-replication (recommended)
or by zero-fill. You should also include the sBIT chunk to convey
the actual data precision.

The PNG spec is available at http://www.libpng.org/ and the scaling
business is described in sections 9.1 and 10.4.

Glenn