What do the opcodes mean for pictures?

[Casey]

I am trying to manipulate pictures at a basic level and I can't find any documentation. Pictures are formed by taking some combination of the old picture, opcodes and data parameters, the new data or picture, a color table, and maybe some other stuff, then casting them into strings and concatenating them together. The result is a picture. Wiring this to a string indicator to try to see what a picture actually is gives an wiring error because the picture and the string are different data types.

I searched the webpage and documetation with no results. I also called in to phone support and they didn't have anything either (which may mean that no one actually knows what the opcodes do).

I'm trying to replace a subset of a pict
ure. I can do it using the Draw Point.vi in a bunch of for loops, but I'm hoping for something a little elegant and fast.

Any help at all with picutes would be appreciated. Thanks,
Casey

[Greg_McKaskle2]

....

> I'm trying to replace a subset of a picture. I can do it using the
> Draw Point.vi in a bunch of for loops, but I'm hoping for something a
> little elegant and fast.
>

The support engineer may not know about the opcodes for the picture
control, but that's fine. They really shouldn't have to. The VIs were
written by R&D, and they are still being maintained and enhanced by them.

You could do what you want in the string domain, searching for and
replacing things inside the picture type, but it would be better to work
at the picture control VI level. You can build up subPictures and
append them whenever you like, storing them into globals, shift
registers, etc.

As for speed, if you need examples to look at that sound similar, you
might want t
o look at the examples that do graphs, polar plots, etc. If
you dig down a few layers, you will find VIs for doing grids, plots,
scales, etc. You may even be able to reuse a few of them. I think that
you will see that they operate pretty fast. Maybe not as fast a a
built-in graph, but fast enough for most operations.

If you have specific questions about how to speed things up, post again
with more details.

Greg McKaskle

[Rolfe]

Casey - Did you ever find an answer regarding the meaning of the picture opcodes? I'm trying to make some custom plots using picture controls which need to update very quickly and which potentially contain many overlapping points. Using the provided picture manipulation tools is not an acceptable solution, since each overlapping point seems to be drawn separately and consequently the control takes too long to update. I tried working directly with pixmaps and converting these to pictures, but the pixmaps/pictures change very little between updates, whereas the picture must be entirely reconstructed from the pixmap on each iteration, which also takes too long. My next move is to try to manipulate picture objects directly, but it would be nice to have some documentat
ion.

Thanks,
Jason

[rolfk]

Rolfe wrote:

> Casey - Did you ever find an answer regarding the meaning of the
> picture opcodes? I'm trying to make some custom plots using picture
> controls which need to update very quickly and which potentially
> contain many overlapping points. Using the provided picture
> manipulation tools is not an acceptable solution, since each
> overlapping point seems to be drawn separately and consequently the
> control takes too long to update. I tried working directly with
> pixmaps and converting these to pictures, but the pixmaps/pictures
> change very little between updates, whereas the picture must be
> entirely reconstructed from the pixmap on each iteration, which also
> takes too long. My next move is to try to manipulate picture objects
> directly, but it would be nice to have some documentation.

You can't do magic with those opcodes. It is simply a format NI defined
with the opcode defining what exact data follows in the picture byte
stream. There are no other secret opcodes than the ones you see used in
the subVIs to create Picture Control data.

What you should look at are two possibilities. First the Picture Control
can be used in a mode where it doesn't clear each time before adding new
data. The option "Erase First" in the pop-up menu controls this and you
have also access to this property through the property node. Disable
"Erase First" and then execute a property node "Erase First" with the
value 1 whenever you want to start with a new picture.

For the rest wire the new data to the subVIs to create the points and
wire that picture stream to the Picture Control. The new points, lines,
or whatever will be added to the already existing picture each time
without the need to draw all points again each time. If this is still to
slow the Picture Control simply won't cut it for you.

Or check out the 3D OpenGL examples for the Picture Control released by
NI a few weeks ago. This is however a newly added feature in LabVIEW 7.1
to the Picture Control. It is meant for 3D graphics but could possibly
be used to create other graphics.

Rolf Kalbermatter

[Rolfe]

Rolf -

Erase First is a magical option. However, the plots I'm attempting to control are actually elements in an array of cluster of front-panel objects. I'm trying to display the signals from a variable number of identical data-acquisition channels, so an array of clusters, each of which contains the tools for displaying a single channel, seemed like the way to go. Unfortunately, I can't figure out how to get a reference to a particular element of this array, so I can't control the Erase First state of each picture object independently. Do you have any ideas?

Perhaps I can set the controls to never erase, and just draw a big square of the background color over them whenever I want to clear them...

Thanks for your help,
Jason Rolfe

[Wiebe@CARYA]

Hi,

If you put everything you draw in a buffer, you can calculate the offset in
the picture string. Just remember that when you concatenate two pictures,
one or two words are removed from the last. In the buffer you can keep all
the offsets, and lengths of the elements. This is a lot easier then
reversing the format of the opcodes.

Regards,

Wiebe.




"Rolfe" wrote in message
news:5065000000050000004ABA0100-1079395200000@exchange.ni.com...
> Rolf -
>
> Erase First is a magical option. However, the plots I'm attempting to
> control are actually elements in an array of cluster of front-panel
> objects. I'm trying to display the signals from a variable number of
> identical data-acquisition channels, so an array of clust
ers, each of
> which contains the tools for displaying a single channel, seemed like
> the way to go. Unfortunately, I can't figure out how to get a
> reference to a particular element of this array, so I can't control
> the Erase First state of each picture object independently. Do you
> have any ideas?
>
> Perhaps I can set the controls to never erase, and just draw a big
> square of the background color over them whenever I want to clear
> them...
>
> Thanks for your help,
> Jason Rolfe

[Rolfe]

I'm not sure exactly what you mean by a buffer in this context. When I tried to directly modify the picture string, I determined which pixel I wanted to modify, from which I calculated the raster-order index (x + y * num_cols), and then modified 3 consecutive bytes of the picture string starting with number_of_garbage_bytes + raster_order_index * 3, where number_of_garbage_bytes is the number of bytes preceding the array of U8 -> string generated by Draw Flattened Pixmap and 3 corresponds to the fact that I was using 24 bit color (= 3 bytes * 8 bits/byte). The images generated via this method seemed a little bit off...

Regardless, I switched over to setting Erase First to FALSE for all of my graphs, and just drawing a gray rect
angle to erase old points. This is really, really fast, both in terms of calculating the desired image (less than a millisecond, whereas things like Draw Flattened Pixmap take many milliseconds) and drawing it to the screen (about 2 milliseconds to render the screen, whereas it can take an arbitrarily long period of time to draw a picture with a large number of points).

So it seems as if my problem is solved. Thank you all for your help!

Jason

[Wiebe@CARYA]

Hi,

Well in case you still want to know...

A buffer in this case is a while loop with a case in it. The case is wired
to an enum, with some functions (like add, get, delete, etc.). The while
loop only runs one, but is used to store information (like size offset,
data, etc.). This data is stored in the loop's shift register.

If you just want fast pixel drawing, you can perhaps draw a 2d array with a
modified Draw Flattend Pixmap. Note that this vi converts the flattend
pixmap to a 2d array (and does a lot of overhead things, just to make it a
general function). Remove all the overhead, so that it suits just your
special case, and you have a fast 2d array drawing vi. This only pays of if
you draw a lot of pixels in the 2d array before actually drawing it.

Regards,

Wiebe.





"Rolfe" wrote in message
news:50650000000500000055BA0100-1079395200000@exchange.ni.com...
> I'm not sure exactly what you mean by a buffer in this context. When
> I tried to directly modify the picture string, I determined which
> pixel I wanted to modify, from which I calculated the raster-order
> index (x + y * num_cols), and then modified 3 consecutive bytes of the
> picture string starting with number_of_garbage_bytes +
> raster_order_index * 3, where number_of_garbage_bytes is the number of
> bytes preceding the array of U8 -> string generated by Draw Flattened
> Pixmap and 3 corresponds to the fact that I was using 24 bit color (=
> 3 bytes * 8 bits/byte). The images generated via this method seemed a
> little bit off...
>
> Regardless, I switched over to setting Erase First to FALSE for all of
> my graphs, and just drawing a gray rectangle to erase old points.
> This is really, really fast, both in terms of calculating the desired
> image (less than a millisecond, whereas things like Draw Flattened
> Pixmap take many milliseconds) and drawing it to the screen (about 2
> milliseconds to render the screen, whereas it can take an arbitrarily
> long period of time to draw a picture with a large number of points).
>
> So it seems as if my problem is solved. Thank you all for your help!
>
> Jason