Picture and PDA

[chilly_charly]

I'm trying to use the new PDA write bitmap file to save an image created on a Pocket PC. Is there any way to create the image data input since the GetImage invoke node is not supported on PDA ?

[daviddelebecque]

Hi Chilly Charly,

You're right. It appears as though there is no way whatsoever to output image data using PDA-compliant VI's. I am going to check this with the PDA experts. Let me some time to see if there is a workaround...

Regards

David DELEBECQUE - Applications Engineer - NI France

[daviddelebecque]

Hi,

After checking with the PDA experts, there is indeed no workaround to this issue. A note will be created requesting that some form of Draw Flattened Pixmap.vi be added to the PDA palette. This VI would convert the picture data type into the Image Data type needed to write a BMP file.

For the moment, there is no way to do that.

Regards,

David D. - Application Engineer - NI France

[tst]

As a really-not-fun solution, since BMP is an uncompressed format, you could probably write VIs which will actually build the file by reading about the BMP format specs. The main reason I would be afraid of something like this is the PDA module's historic unreliability when it comes to handling byte manipulation and things like that. Also, I'm not sure how fast such an operation would be when implemented in LV PDA.

If you do come up with it, I'm sure I could use at some point, though...

[chilly_charly]

---

tst a écrit: ...If you do come up with it, I'm sure I could use at some point, though...

---

Sorry Tst, but I have no time for that 🙂

I had planned to finish an application, using extensive graphic operations, within a month. But I'm discovering that the LV PDA module (LV 8), is still far from what we could expect. The graphic capabilities and more specifically drawing, should be improved significantly before something with a professionnal look and feel could be produced. Therefore my application will probably be a mess, and I 'm terribly upset...

For instance, there are still no sliders on picture controls ! 😮  and of course no zoom function either ! 😞 😠
Well, even if we can't save an image, we have two different vis, side by side, to open bmp files, and of course these spendid 3D controls... 😛

I'm not sure I'll be able to champion the LV platform solution to work on PDA's.

[tst]

I seem to have made a mistake in understanding. The saving to BMP is not a problem, because that code is freely available inside the regular Write to BMP VI. The problem is actually with extracting the data from the picture string. For that, you can either:

a) Analyze the string and extract the information (not fun).

b) Try taking the standard Picture to Pixmap VI and copying it into a LV PDA window. It seemed to work for Ed with one of the string primitives and if it doesn't have any special code it should hopefully recompile, even if it is locked (a lot of fun).

c) Sorry, can't think of a third option (the most fun, means you don't have to do any work at all ).

[chilly_charly]

---

tst a écrit: ... b) Try taking the standard Picture to Pixmap VI and copying it into a LV PDA window. It seemed to work for Ed with one of the string primitives and if it doesn't have any special code it should hopefully recompile, even if it is locked (a lot of fun).

---

That was again a good idea... Unfortunately, I get an error message : "PictToPix is a missing vi or C file"

I'm sure that somebody at NI has the missing function, because I can't believe it could be possible to build a tool palette where files can be opened, created, but not saved, while a write vi is proposed. That should be the kind of silly mistake that you do when in a hurry... or somebody has been cheating !.. Let's wait and see !

May be I don't need this function at all. Let me explain my problem : In my application, the user has to do a lot of drawing  (that's why I posted few weeks ago a benchmark vi). The lines can be recorded as series of XY coordinates, and saved in a file. The drawing will be viewed at different scales. The speed limiting step is not the drawing operation itself, it's the way LabVIEW manage the data string. Therefore, I would like to convert the line picture into a bitmap picture, because I believe that the display would be more rapid. But may be I'll run into memory size problems...

Thanks for your help !

[tst]

chilly charly wrote:

---

tst a écrit: ... b) Try taking the standard Picture to Pixmap VI and copying it into a LV PDA window. It seemed to work for Ed with one of the string primitives and if it doesn't have any special code it should hopefully recompile, even if it is locked (a lot of fun).

---

That was again a good idea... Unfortunately, I get an error message : "PictToPix is a missing vi or C file"

---

Then I'm guessing that that VI has a CIN or a DLL call or something like that which converts the picture string (although I don't know why they would want to hid something like that). I assume that's what David meant when he said that there is no workaround.

If this will only be used in your application, how about flattening it to a string and saving that string to a file and then reopening it and unflattening on the reverse route?

I tried to do something like that in 7.0 PDA once and I couldn't manage to open the file (it was about 500-1000 KB), but I don't remember what I did to work around it. I may have just placed the data as a constant inside the diagram.

[chilly_charly]

Saving the data is not the problem. It's converting them to a bitmap !

The idea is that LV can display more rapidly a bmp picture than a vectorial drawing.
Try to use the drawing example shipped with LV PDA. After drawing a few lines, the drawing rate slows down dramatically and the vi becomes unusable. The problem is related to the management of the data string.
Things can be improved a bit but not much, and I'm still far from being able to build a vectorial drawing board with LV. That's why I'm trying to find another way round and switch to bitmap data.

I wonder if there is a solution to use the Word PDA drawing tools ?

[tst]

Wait a minute...

Let me tell you how I see it, and tell me if something is wrong.

The only picture LV knows internally is the picture type, the blue wire (one of their AEs called it picc once, so I will use that name), so eventually you will have to use it. This is basically a string for building a vectorial image and can be both manipulated with the string functions and displayed using the picture indicator. When it has a BMP image it simply describes it byte by byte.

Now, if I understand correctly, the speed problem happens when handling the string inside the picture functions. Flattening to a string and unflattening simply gets around all that. You will literally be saving it as a bitmap (or a bytemap, in this case). The only problem (the one which I ran into) is the file size. Even when using 8 bit indexed color, an uncompressed picture with a size of 200x200 will be about 40KB. That doesn't sound like a lot at all, but as far as I rememeber, 7.0 had a problem with it. I suppose it is possible I was trying to use the default 24 bit color which would have made it bigger, but in any case, 8 will probably be better.

In any case, there doesn't seem to be any support in LV for a true bitmap. A non-vectoric image is simply taken byte by byte and appended to the picture string (apparently by using opcode 29, look at the Draw Flattened Pixmap VI). The picture control itself is what turns the string of commands into visible picture on screen. If you really want, you can try to reverse engineer the DFP VI, but I don't think you will get anything out of it, as I'm fairly certain flattening to a string would be faster.

If you want to work faster after your program started running, you could probably theoretically calculate what you want to build and build the byte array directly yourself, but that will probably be a tricky bit, and I'm not sure it will outperform the string concatenation (unless you set some rigid rules and use replace instead of build).