Rotate and Flip 2D Arrays

[Andi_S]

Currently I'm still using LV 2009 so I hope the suggestet feature is not already implemented in the current version of LV 😉

******

I'm missing array functions for rotating and flipping 2D arrays. For images (NI-Vision toolkit) similar functions are available.

Of course I can program each function manually but low level functions would be really nice.

Let's make an example. The 3x3 input array is:

1 2 3

4 5 6

7 8 9

transposing (the only function that is already implemented) deliveres:

1 4 7

2 5 8

3 6 9

90° rotation should deliver:

3 6 9

2 5 8

1 4 7

horizontal flipping should deliver:

3 2 1

6 5 4

9 4 7

vertical flipping should deliver:

7 8 9

4 5 6

1 2 3

[X.]

These sound like neat functions, the only question is: what purpose do they serve? You will get traction only if there is a real general benefit from having them for ALOT of people. I am not familiar with any linear algebra that requires the kind of transform that you are talking about, but I'd be happy to learn...

If you are using the Vision Toolkit, why not use those functions?

[Andi_S]

You're right, the reason comes more from image processing than from a math purpose.

Some operations can be done more easy with arrays than with images and it's very annoying to convert from image to array and back all the time.

[Ludwig72]

As I remember, there is a vi in the OpenG array functions for this cause.

[X.]

@Andi S: BTW, the result you are expecting for horizontal flipping has a typo in it.

@Ludwig72: You mean "Reverse Array"?

That's still a VI... and it does not do the 90 degree rotation. You would have to combine it with a transposition. But, that certainly look like a valid workaround to me. (Virtual) kudo! 

[Darin.K]

I could see a potentially useful scenario, but I would probably suggest that it would apply to the matrices and not necessarily 2D arrays. In C++ (and others) you can implement these simply by switching indices or doing simple pointer math. You do not (always) have to go in and shuffle the actual elements. There could be a flag in the datatype to indicate if a matrix was say transposed. If you get an element, the primitive could see the flag and take care of the index swap for you. This could make these operations "free" in many cases, much like Reverse Array does for 1D. Since Matrices are defined to be 2D (how about more datatypes please), it could makes sense to add these flags there instead of treating 2D arrays as separate beasts (not that I would complain about that). The line between primitive and VI performance is getting blurry. The biggest advantage for the primitives remain type adaptation, however these operations are usually done on a limited subset of datatypes (ie. 90% DBL, 9.9%I32, 0.1% for me).

[X.]

Something like what I am attaching to that post (can't attach anything here) does the job more efficiently than the Open G VI. A Polymorphic version would help...

[GabbyG]

I remember having the same problem.

This was also doing image processing and I had to write my own rotate and mirror library in C.

That was the 7.11 time but I think doing this job on a 4000x4000 pixel image is still not really fast in native LV.

Connecting a Code Interface node was not to difficult. Of course if you are no expert in Visual C, setting up that compiler is some task alone, but it might be useful for some number crunching in a "real" pointer area.

Gabi 

[X.]

@Gabi: the initial request was for arrays, not images (even though the starting point were images, apparently). The fact is that not everybody has the Vision Toolkit, so that request makes some sense. Andi S specifically mentioned that he was not excited by the perspective of going back and forth from image structure to array, which I understand. Now, there are already VIs for these operations in the toolkit (Except for transposition AFAIK), so you could ave saved yourself the CIN detour:

@Darin K: I am not sure how matrix data is stored, but from my dealing with 2D arrays within CINs in the past, I remember that their structure is not really amenable to easy pointer juggling (see e.g. this example), especially in the case of rotations. Even in the case of a symmetry around the horizontal axis, I am not sure how you could handle this efficiently (I mean storing a flag with the array saying "handle this as a vertically flipped piece of data")...

I haven't benchmark my solution, time and memory-wise, but that could be interesting to do (as well as improve on it).

[GabbyG]

@X: Yes you are right for IMAGES there are routines.

Our Problem came from a special kind of "image". we were collecting surface data in am image like fashion. No camareas involved. Also processing would happend  in a pure array of I16 representation. Alone the size of 4000 by 4000 pixels was hard to handle. But thanks for pointing out the image.

Gabi 

[KiwiWires]

A nice example from @altenbach here. I saved as a VIM to handle different array types.

https://forums.ni.com/t5/Example-Code/Simple-2D-array-transformations/ta-p/3511510?profile.language=...