low performance on 2d array operation

[altenbach]

Also note that you have of course 8 surrounding pixels, not just 4.

You also need to possibly correct for edge effect if indexing outside the valid data area.

[MF0088]

Images I'm looking at in my experiment occupy roughtly 1/3 of the sensor area, in the center, and features are usually about 6*6 pixels large, so using 4 or 8 surrounding pixels won't make a huge difference. Another camera I use has this filter interagrated and it uses 4 pixels, so for the sake of consistency I'm probably going to use only 4.

[Blokk]

I am not sure if it was suggested before in the posts, but for such image processing tasks a video card is a very good candidate.

http://sine.ni.com/nips/cds/view/p/lang/en/nid/210829

Depending on the 2D array size, you can get nice performance increase.

[Yamaeda]

---

@MF0088 wrote:

Indeed the operation is done in 2-3 seconds on my desktop computer using shift registers.

Thanks for you help here.

I know the code is abolutely not optimized regarding boundary conditions, if 2 adjacent pixels are deffective and number of times I call Increment or Decrement, but it was a rapid VI I made on a test file that could not fail these tests. I will work on that but I know how do it it.

For what it's worth, here is what I have now, as a working solution.

---

If you do the Filter comparison in the inner loop you don't need to create a 2D-array, which should be slightly better. You can also change the Quotient&Remainder to a Bitshift 2 right (same as divide by 4) for some speed optimization.

Also, do one +1/-1 and split the wire. It's not many clock cycles difference, but out of principle. 🙂

The Indes array don't need the 0- and 1-indexators, it's the default.

/Y