Picture to Pixmap (8-bit input) not returning colors array

[AristosQueue (NI)]

PS: The above VI was written in LV 7.0.

[lanmat]

Here's an update on what I've been trying. The last vi I attached above doesn't really work as it's waaaay too slow for large images and even when I 'fixed' it by using decimate array to break up the RGB information in the 24-bit image array, I would often get images that were skewed to the right at 45 degrees.

I found out that every once in a while, the image would need an extra column of zeros on the right hand side to save or convert to picture correctly (otherwise you end up bitshifting the pixels each row). Since the image array is 1-D, it was a little tricky to get the zeros in the right place. But then I had a few images that were skewed to the left. This was caused by putting the trailing zero column when it didn't need it. This only happened when I was adding anything to the picture (such as a border by placing the loaded image somewhere in the middle of the picture). Even then it didn't happen for every picture, but it definitely was repeatable. It seemed to be size related, too. I'd take a 1024x1024 8-bit grayscale image and it would come out skewed. I'd reduce it to 512 x 512 and it'd be fine. A 5x5 pixel picture also has that ending column.


Then there's the interesting bug that certain binary (white/black) images don't load with the correct color table from the read .bmp vi. I have a few binary images created with matlab that open correctly, but I go and make a binary doodle in photoshop and the picture it's converted to is all black.

Needless to say, I'm kind of at my wits end on how to open an arbitrary grayscale (1;8;24-bit) image, add a border with text and other test features and resave it as an 8-bit grayscale image completely within LabVIEW without using NI Vision. It seems like Picture2Pixmap is doing something funky with the image array and that optional size dependant trailing column of zeros.

I'm attaching the current version of the grayscale converter and some spaghetti code I've been using to test stuff out with. Everyone feel free to play around and see if the above goal is possible. Go ahead and make an 8-bit gray 1024x1024 test pattern and see if when you turn off the border adding code if the skewing doesn't happen.

[lanmat]

hmm...can't find out how to attach 2 things at once. Oh well...here's the other vi necessary for the above one.

[lanmat]

...and apparently in my trying to attach 2 things, the first attachment is no good...here's the tester program.

[lanmat]

Anyone had any luck with this? I'm trying to see if I can get my hands on a copy of Vision just to see if it could work there, but in the event I can't, can anyone find a way to create and save (or convert to) an 8-bit grayscale bitmap in LabVIEW and have it not skew the image for any test image?

[zou]

I can create a vi to convert the return of Picture to Pixmap.vi for 24 bit, originally loaded as 8 bit, back to 8 bit.
Color instead of grey scale if you instereted.

George Zou
http://gtoolbox.yeah.net

[Johnner]

A final two cents from me: have you considered biting the bullet, performing all your manipulation in LabVIEW using 24-bit data, and then reducing the color depth of the resulting BMP files after the fact?

I would suggest this method, since it just seems like a mess to build your own color reduction functions in LabVIEW, and there are some good open-source tools out there to handle that step. In particular, I suggest installing Imagemagick (available on any platform you can think of) and using the following command with System Exec:

mogrify -colors 256 +dither [FILENAME]

Problem solved, even if it's not in LabVIEW. The cost is nothing, and there's probably as much or more image-manipulation expertise behind that function as you might find in the equivalent IMAQ Vision function or anywhere else.

--John

Message Edited by Johnner on 03-10-2005 07:27 PM