Why "check data size.vi" does not accept odd values as width of an image?

[Tociek]

Hello everybody!
I'm trying to save a file with "Write PNG File.vi" from the data I use in Intensity graph. When I try to save an image with width that is an odd number, "check data size.vi" throws an error, beacuse after it's recalculations he gets "my width" -1 as actual width. Does anyone knows why it doesn't accept odd values? (Rigth now I just use even numbers for width and it works).
Tociek

[chilly_charly]

Never noticed such a behaviour. Could you post an example of your problem ?

[Tociek]

This is the vi in which I had this problem. It saves data from intensity graph with resize option (data is then interpolated)

[altenbach]

You can open and inspect "check data size.vi", it is not passworded. (Easiest from the VI hierarchy window).

Curiously, for 1, 4, and 8 bit data it forces some intermediate result to be even before comparing it with the size of the flattenend image data array. I dont' see why this needs to be done?

Maybe it's a bug?

[altenbach]

Btw: "write jpg.vi" uses the same check size subVI. It might have the same problem.... (not tested).

[chilly_charly]

Could not do much work on your vi since no data is attached. However I did some trials with a few pictures.

The error occurs only when there is a discrepancy between the image array size and the rectangle dimensions or the color table size (not required with 24 bit images). 

With 24 bit images, the image array size must be equal to W x H x 3.

With 8 bit images, the image array must be equal to W x H, and you must provide a color table with 256 colors. Moreover, images must have an even width (don't ask why).

[Tociek]

>

---

@chilly charly wrote:

Could not do much work on your vi since no data is attached. However I did some trials with a few pictures.

...

With 8 bit images, the image array must be equal to W x H, and you must provide a color table with 256 colors. Moreover, images must have an even width (don't ask why).

---

Sorry for not attaching any data... My mistake 🙂

> With 8 bit images, the image array must be equal to W x H, and you must provide a color table with 256 colors. Moreover, images must have an even width (don't ask why).
That's what I wanted to know, actualy... Now, as you can see in my code, I have protection against odd width... I was just curious why it is necessary...
Tociek

[altenbach]

If you make the following simple change to "Check Data Size.vi", it will write PNG files with odd width just fine. (Warning: Do this only for testing, without saving the modified VI. You should NEVER permanently modify system VIs!).

I don't know why LabVIEW insists on even width for palletted PNG, but maybe there is a hidden reason somewhere (Maybe there is a very good reason!) Could it be needed for use in the JPEG version? I have quickly glaced throught the specifications, but did not find anything obvious.

And yes, CC, I always ask "why?". 🙂 Why? Why?? Why???

Hopefully, an expert from NI will chime in and enlighten us. Did you report this to NI?

Message Edited by altenbach on 08-29-2005 09:16 AM

[Tociek]

Actualy I have already tried to remove this part of code 🙂 But then I got messed up picture (attached). So I think that it is somehow necessary...
No, I haven't reported it to NI... I'm programming LabVIEW for 2 months so my first thought was that there is some reason for this, that I simply can't see 🙂