How best to troubleshoot image display trouble?

[jjsword]

I have a 12 bit Zeiss MRm camera and am trying to capture images and display them to the Image Display.   I have a U16 array that I place the pixel data into but the display is not correct at all.  This is a continuation from a previous post that I had and there were some good suggestions from BlueCheese on how to fix this but I am still stuck.  Can anyone advise what would be a good methodical approach to troubleshoot why the image displays this way?  There is a random matrix that is generated in this program that puts in random numbers 0-4095 for the pixel values instead of capturing an image from the camera and it displays fine.  Thanks!

[BlueCheese]

From my previous post:

---

If I had to guess I'd guess that your code is not taking the line padding (stride) into account. Vision images always have each line aligned on a certain boundary. I think it is often 64-byte aligned on Windows systems. This padding is an output on the Map Image Pixel Pointer VI. You could also modify your image width to match the byte alignment so that there is no need for additional padding

---

It looks like your DLL is putting less image data per image line than is actually in the image, causing it to start putting the contents of the next line onto the previous one. This is because it is likely not following the line stride of the vision image data.

The line stride is going to be a function of the border on the image (specified when you called the IMAQ Create VI -- defaults to 3 pixels), the size of each pixel (2 bytes in this case), and the width of the image. If all of these factors do not combine to a multiple of the padding side (retrieved from Map Image Pixel pointer) then your DLL needs to skip a bit of memory in the destination buffer after copying each line into the image.

If you don't want to add this complexity into your DLL, you could cheat by always creating your images with a border of 0 and ensuring the the image width is always a multiple of 32 or 64 pixels. This would guarantee 64 or 128-byte alignment, respectively, which would likely satisfy alignment restrictions expected by Vision images. Note that the required alignment is platform and system dependent and is not guaranteed to be constant---this is why it is an output on the Map Image Pixel Pointer.

Eric

[jjsword]

I guess LabView expects that the dll won't put data in the alignment pixels.  I am surprised that there isn't a way to tell the display that the data is an X by Y continuous array and adjust accordingly.  The dll definitely does put the pixel values in without gaps so I am trying to figure out how to adjust the width to be a multiple of 32, since I didn't write the dll.  Thanks!!

[BlueCheese]

LabVIEW displays Vision images in the image display control. Vision images have specific alignment requirements that ensure that they can be used with any algorithms and hardware components with optimal performance. Even if you could tell the display control to use a different alignment we could not guarantee that you could use the Vision image for other uses (such as passing to other algorithms) that may have specific alignment restrictions.

You could also put your data into a LV array (which is always contiguous with no padding) and then use ImageFromArray to convert it to a Vision image. This entails an extra copy vs putting the data directly into the image. You might also need to use a 1D array and reshape the array if the 2D array representation in LV doesn't match the same row/column ordering of your image data (I'm not certain which way it goes). This is generally the easier mechanism but comes at a performance cost. Of course this cost is probably in the range of milliseconds so it may not be a factor for your application.

Eric

[jjsword]

The LV array was something I was considering but thought if I could get the image array to work then the image array might be easier.  Perhaps not.  Currently I have a buffer of 10 arrays for processing of the images so the performance cost of an extra copy is something I pay anyway. 

There isn't an example of making a series of arrays with a pointer for a LV array similar to what IMAQ is set up for, is there?  Thanks.

[jjsword]

One possibility I thought might work would be to create a ROI that is 1376X1040.  I would need to create a RECT that has values {0, 1376, 0, 1040} and then need to create a pointer to those values as an input to the dll function to create ROI size.  Any recommendations on how to do that, especially with the pointer creation?  Thanks.

[jjsword]

The image finally displayed properly.  I entered a cluser of values {0,0,1376,1040} in for a ROI and that finally did it. I saw another post that said creating a cluster of values and then "adapt to type" would have Labview making the pointer and passing it to the dll function.  Thanks so much.