Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

IMAQ Write PNG rescaling greyscale images (bit depth) after migration to Labview 8

Hi all,

I recently upgraded to Labview 8 with some slight problems (see http://forums.ni.com/ni/board/message?board.id=200&message.id=9008 ) which were overcome after help from the messageboard. NB the IMAQ Write PNG vi I am using is literally identical to the old one.

However, now my program which writes greyscale images taken with a 10 bit grabber stretches them to take the full 16 bit range rather than just giving the pixels values from 0 to1023 they range from 0 to 65535. I don't understand why this is the case as it is the same IMAQ Write PNG.vi (due to the steps taken in the previous board).

This is very similar to what happened when I used a firewire camera some time ago. (See http://forums.ni.com/ni/board/message?board.id=200&message.id=6258 ).

It is a real pain dealing with stretched images.

Is there any way to keep the numbers recorded in the PNG file to be 0-1023?

Cheers,

Greg
0 Kudos
Message 1 of 5
(6,558 Views)

Hi Greg,

When you use the new Write to PNG file you will find that there is a new input on the bottom of the vi.

What you need to do is simply wire a true constant into the input "Use Bit Depth?" this will use the 10bit bit depth that you have.  It will create a 32 bit image, however only the first 10 bits will have the information in. (you should see the image get a lot darker when you wire this option up.

I hope this helps. Please get back to me if you have any other questions.

Thanx

AdamB

Applications Engineering Team Leader | National Instruments | UK & Ireland
0 Kudos
Message 2 of 5
(6,535 Views)

Hello,

 

I have the same problem, when saving 16-bit greyscale images to PNG. When reading them in LabVIEW the pixel values are OK, but reading in Matlab or ImageJ, a rescaling is applied, wether the "bitdepth" input to the Write VI is true or false. So I assume that there is some info in the PNG header that  IMAQ ReadFile uses.

 

Is that a bug? Currently I have no way of saving my 16 bit images in a standard format, that can be read correctly by other software, which is somewhat frustrating

 

Any help appreciated!

 

Charles

0 Kudos
Message 3 of 5
(6,183 Views)

Hi there,

 

I spent a lot of time using pngs in c++ after encountering this problem. (I ended up writing my own reader using libpng, though it's been quite some time since I moved onto other things.) The PNG format is actually really neat.

 

There is an sBit 'chunk' which says what the true bit depth of the image is. (The chunks idea is great as you can put anything there in the custom chunk if you want.) The standard way of dealing with images with bit depths not 8 or 16 bit is as follows:

- write in the sBit chunk what the real bit depth is.

- shift the values to fill the full bit depth

- copy the most significant bits into the least significant bits

    eg imagine the 6 bit pixel    110101      This goes to   11010111.

The MSB replication is a good idea as it means the image uses the full scale - white is still white and black is still black.

The sBit chunk simply reminds the reader of the image that the extra data (the 2 last bits in this example) are fake. When the file is read back in the values can be shifted back to the true bit depth.

 

Originaly Labview (7.0?) didn't seem to do this shifting which I'm pretty sure is non standard. This made 10bit greyscale images really dark when viewed with a normal viewer.(I thought this was a good thing at the time as I was interested in the exact pixel values). Then when LV8 came along it fixed this 'problem' (the firewire add-on also fixed it) things stopped working properly for me. Here's the thread that helped me: http://forums.ni.com/ni/board/message?board.id=200&message.id=6258

(You can see my inital confusion about the MSB shifting.)

 

What version of LV / IMAQ are you using? Post an image (telling me the BD it is meant to have) and I'll try to have a look at it with my reader.

 

Greg

Message 4 of 5
(6,174 Views)

Hi Greg,

 

That's right, a simple bit shift did the job! Matlab sucks, it should have done it by itself... Thanks a lot for your  precious help

 

Charles 

0 Kudos
Message 5 of 5
(6,166 Views)