Rotate and Shift 16-bit Image

[SJT]

I would like to rotate and shift a 16-bit RGB image (U64 in LabVIEW).  The IMAQ rotate and shift functions don't accept this image type, but they do accept a 16-bit grayscale image (I16 in LabVIEW).  Unfortunately, this clips all values in my original image since it runs from -32,767 to + 32,767.  The ExtractColorPlanes function requires a 16-bit image to be wired as the desination image but the IMAQ create VI does not allow U16 image to be created.

Any ideas?

[SJT · Accepted solution]

Just to be proactive... Here's a sample of the problem.  I tried uploading a (small) 16-bit tif, but its not a valid extension to upload.  Photoshop allows me to save a 16-bit as RAW, TIF or PSD: none of which can be uploaded.  So sorry for the inconvenience. 

[SJT]

This question has NOT been solved, so please continue to respond.  Does anyone know how to deselect the "Problem Solved" button/logo?????

[chilly_charly]

You can upload any file : zip it first !

[altenbach]

---

SJT wrote:
This question has NOT been solved, so please continue to respond.  Does anyone know how to deselect the "Problem Solved" button/logo?????

---

Try the "options" link in the upper right corner of the post. (Select: "Unmark as accepted solution")

Message Edited by altenbach on 12-29-2008 09:17 PM

[chilly_charly]

---

SJT a écrit:

I would like to rotate and shift a 16-bit RGB image (U64 in LabVIEW).  The IMAQ rotate and shift functions don't accept this image type, but they do accept a 16-bit grayscale image (I16 in LabVIEW).  Unfortunately, this clips all values in my original image since it runs from -32,767 to + 32,767.  The ExtractColorPlanes function requires a 16-bit image to be wired as the desination image but the IMAQ create VI does not allow U16 image to be created.

---

IMAQ Create can create U16 images, but the standard Image Type input lack the appropriate value. This is bug n°1 . As workaround, you can either wire directly a con,stant with value 7 or dig into the Vision palettes and get a better typed constant from the IMAQ Cast Image VI.

However, this is not the solution to your problem, since there is the n°2 bug in the IMAQ ExtractSingleColorPlane VI : it doesn't accept U16 or U64 as destination images, and coerce the output to a I16 default image type.

A workaround is to create your own color plane extraction function. First convert the U64 image into an array, then extract the desired plane, as shown on the diagram below.

Message Edité par chilly charly le 12-30-2008 08:31 AM

[chilly_charly]

And, using the attached example image, you should get the result below.

Message Edité par chilly charly le 12-30-2008 08:35 AM

[chilly_charly]

Of course, your problem is still not solved, since the IMAQ rotate VI doesn't accept U16 as valid input image.

Although this is documented, it is such an unexpected limitation that we can consider it as bug n°3 ;).

So either we are stuck here, or we accept to loose the last bit of information... 

To avoid clipping, we could divide the image by 2 then coerce it to an I16 image... if the IMAQ Multiply accepted U16 images.

But that's not the case (bug n°4 ?).

So we have to convert the image to an array, shift the U16s one bit to the right, then convert the array to an I16 image, rotate it, convert it to an U16 array, shift-left one bit to recover to the proper dynamic range, and convert the array back to an U16 image, as shown on the diagram below. Ouch !!!

Message Edité par chilly charly le 12-30-2008 10:26 AM

[SJT]

Chilly Charlie,

Thank you for your quick response.  I was afraid that the image types were completely tangled, but not surprised.  It makes you wonder who decided on the original high-bit image types (16-bit unsigned floating point but not 16-bit unsigned integer??).

I'll need to evaluate the amount of processing that is required to convert arrays back and forth to determine if this method is feasible, but I appreciate that someone confirmed these bugs.