2D Picture Translation (movement)

[mje 187]

I have a situation where I have some pre-rendered picture data and I wish to translate it by some number of pixels. This is what I came up with:

 

 

Problem is though the intermediate pixmap format completely flattens the data, thus removing any trace of vector based content that was in the original picture (blue wire). Is there some operation I can do that will translate all coordinates in an existing picture string?

[Norm Kirchner 99]

Which version of LV are you working on?

I have just the thing that you're looking for.

Also, how many elements are on the picture?
a lot of line art, or a bunch of images?

[mje 187]

Hi Norm, that's great news! It's just a combination of the existing line/text/shape operations, there's no image or bitmap data. I can't imagine there would be more than 100 elements in the string since I'd be handling the translations at a pretty low level before too many of the picture strings are concatenated.

Also, LV2013.

[Darin 154]

Somewhere in my harddrive is buried a library which scans the opcodes of a picture and applies translation, scaling and rotation.  The text rotation and scaling and bitmap operations are a bit involved, and I never bothered to deal with rotating greyed out rects, (other rects are converted to polylines).

 

It is kind of cool, but I would probably not get too close to "real" code with it since it is deep into hack country.  What it also did was delay me from doing what I really should have done earlier, implement a real OOP drawing library.  Implement a few basic shapes (start with the LV Picture primitives), and a group or collection object.  Each object gets an origin, angle and scale and methods to translate, rotate and scale.  Now instead of blue squiggly wires everywhere you get (blue in my case) class wires everywhere.

 

And then you can reach nirvana, retire the LV picture functions altogether.  The render method of the objects can be overridden to be LV Picture, SVG, eps, Canvas, .NET, whatever.  Once you see a few anti-aliased lines, circles and text you will never want to go back.  IE (easiest browser for ActiveX integration) is closing the gap with the better browsers on handling HTML5 and SVG, it simply unleashes a whole new world.  Rotated text caused problems last time I tried with IE so it is not all systems go quite yet.  But it is getting close.  Of course, it not only has to be fixed in the browser, but fixed for long enough that it becomes reasonable to require users to update.

 

But I digress, you probably need to get to point b from point a so Norm will likely be posting an opcode parser in the not too distant future.  I'd post mine, but the bitmap and rotation handling bloats it considerably and the fact it comes from LV3 or 4 makes for interesting reading.  [it says a little about LV3/4 and a little about how I programmed when I was using LV3/4 (not to mention it started as a hack).]

[mje 187]

Indeed. I have some proof of principle code laying around that takes XML data from one of our applications and produced an HTML report with embedded SVG for things like chart data (via some stylesheet transform-fu). Slap that in the right browser and it was beautiful. Not so much that the graphics looked that good (it was only a proof after all), but beautiful from an elegance stand point: you had a portable (single file) report with all the styles and graphics directly embedded which could be rendered potentially on any target with any resolution to high fidelity.

 

I'm so on board with what is possible with an overhaul of the picture palette. I find most of my displays now revolve around pictures now. Even my graphs really only use the graph/chart element for the cheap anti-aliasing and scale rendering, then a whole mess of business dropped into the plot image layers. Not that I'm belittling graphs and charts-- it's so nice to be able to drop an array of doubles/clusters/whatever into a control and just have a plot work with no worry, however the rest of the functional elements are little rough around the edges. I don't really like the way cursors, annotations, digital displays, etc are implemented, so I usually roll my own with supplementary plot images and mouse tracking.

[Norm Kirchner 99]

Ok,

Check out the demo in the ZIP file

 

It's not hack code, but is definitely missing documentation.

So in lieu of that, here is a narrated story time

 

http://screencast.com/t/dJsMkZkDA0

 

http://screencast.com/t/9dgIuC97LZwP

 

Ports back to LabVIEW 7.0 at least (original code from 2003)

 

~,~ 

The Captain Was Here

My Source Distribution.zip

[mje 187]

Norm, that is a fantastic walk through. I can't thank you enough.

 

Cheers!

[Darin 154]

It's not hack code, but is definitely missing documentation.

 

It is cool, very, nice, very well-written, nicely laid out with great icons and all of that, but until it sits in vi.lib (like it should!) and/or I can open up the detailed help on Flattened Data and see the picture format documented I consider it hack code.  It is not derogatory, a lot of the coolest code I have relies on undocumented features.

 

And I would double check your value for 'new font', I have it down as opcode x1F and not x00.  Does not matter for simple translation obviously.  Also, my (hack) code does the operation inplace instead of rebuilding the string and seems to be about twice as fast, important for complex drawings.

 

Tips for those who go down this road:

If you are really shifting everything, consider the origin property.

Do not forget that the zoom factor can be !=1.

If you are simulating a drag I would consider using a separate picture which contains the drag objects drawn on top of the picture (I usually draw the drag objects grayed out in the main picture).  This is much better than parsing and reparsing the image if you have relatively complex pictures.

[Norm Kirchner 99]

Oh, most definitely has room for improvement.

Doing the string operations in-place is the best especially if you are doing color replacement, text replacement, or line moves; the user just has to keep a dictionary of 'desired element to offset' lookups.

 

If the code for doing the color replacements or other high performance modification operations is desired, make the request here, and i'll add onto it.

 

Double up on the recommendation for making 'layers of picture controls' to give the ability to show an element moving/ being modified, while the original stays in place.

The application this came from had upwards of 5 layers for different things.

[hemantchourasia 0]

I have a 2d picture .having circle,rectangle etc.and i want to control all picture from front plane using transformation VI then how to do this.As I know transformation VI is 3d picture so thats the main problem that i m facing.

[Norm Kirchner 99]

I have a 2d picture .having circle,rectangle etc.and i want to control all picture from front plane using transformation VI then how to do this.As I know transformation VI is 3d picture so thats the main problem that i m facing.

 

What kind of transformations do you want to do?

Source distribution posted a little above, shows how to take a picture control and get the individual items from the picture and then do some kind of transformations to it.

Namely in the example shown here, it showed lateral translations, but I presume you want to do some kind of rotation or growing or shrinking, Correct?

[rolfk 375]

What kind of transformations do you want to do?

Source distribution posted a little above, shows how to take a picture control and get the individual items from the picture and then do some kind of transformations to it.

Namely in the example shown here, it showed lateral translations, but I presume you want to do some kind of rotation or growing or shrinking, Correct?

 

Don't tell me you are thinking about reimplementing OpenGL on top of the 2D Picture Control!