Unflatten Pixmap unexpected behavior

[JK-USP]

This is not actually a bug in the function Unflatten Pixmap but I see a fail in the function implementation.

It seems that the output is missing the an entire line and collumn of the array corresponding to the input picture.

What is your oppinion ?

[Dave_Brandt]

What version of labview are you using? 

[Dave_Brandt]

I am using 2010 and get the same results when programed like your example. It appears you have found a bug. A work around would be to just remove the decroment from the width and height,  The image data is missing a row and column worth of data so the array size is correct at 99,74.

If you check the Picture to pixmap vi, The image data image array is 24 bit color so it has 3 bytes per pixal for red, green,blue values,

100*75*3=22500 

99*74*3=21978

(100 + 74)*3=522 

174 pixals missing 

[tst]

I think your problem is actually with the draw rect VI - it looks like you shouldn't substract the one.

You can see that you actually need to have a rect where the top and bottom row are different to draw a rect with one row. I have no idea if this is correct or not (at face value I would say no), but that seems to be the source:

[rolfk]

It's correct if you consider the origin of LabVIEW. The LabVIEW pixmap is modelled after the Macintosh PICC format. On the Macintosh the pixels were not located on the screen coordinates but in between. A small but pretty important difference. So a PICC starting at 0 and ending at 10 had 10 pixels across, not 11 like it would have for a Windows bitmap.

[JK-USP]

Yes tst, you're right. I've actually found it a few moments after I'd post the problem, however I forgot to put across.

I'd read in another comment to this subject that this is because of the Mac origin of LabVIEW. How about to fix it now ? 😉

Thanks everybody !

[tst]

---

@JK-USP wrote:
How about to fix it now ? 😉

---

There's nothing to fix, as there's nothing broken. Even if NI did decide to change it now to make it easier to work with, they would have a problem because there's a lot of existing code in the world and even if for a lot of it being one pixel off is not a huge deal, at least some of it will depend on having the correct sizes.

NI probably could deal with this by having the old function as a wrapper for a new function and then let the wrapper fix the values, but in general, the picture control does not seem to have gotten too much attention from NI and I don't know if they would touch it now or simply come up with something else to replace it (for instance, something which can do proper vector graphics, aliasing, hardware acceleration and so on).

[rolfk]

---

@tst wrote:

---

@JK-USP wrote:
How about to fix it now ? 😉

---

There's nothing to fix, as there's nothing broken. Even if NI did decide to change it now to make it easier to work with, they would have a problem because there's a lot of existing code in the world and even if for a lot of it being one pixel off is not a huge deal, at least some of it will depend on having the correct sizes.

NI probably could deal with this by having the old function as a wrapper for a new function and then let the wrapper fix the values, but in general, the picture control does not seem to have gotten too much attention from NI and I don't know if they would touch it now or simply come up with something else to replace it (for instance, something which can do proper vector graphics, aliasing, hardware acceleration and so on).

---

Fully agree here. This is not a bug but "unexpected" behaviour at most. And as such there are two possible solutions, one being to change the behaviour and the other to change the expectations. The first option is after 20 years of existence of the Picture Control not an option at all. The best you can hope for if you report it as bug is that the documentation is amended to point out this behaviour more explicitedly.

As to a more functional control, it already exists as the 3D Picture Control which uses OpenGL internally. Still not the egg producing, wool spending pig that some would want, but at least offering vector based operations.