I do not have an explanation, yet, but some observations to share.
Using the modified VI GregS posted, I expanded output indicators and changed the display format to show 15 significant digits. Looking only at the subVIs which can work from start index =1 and data = max, I see differences starting at a square array if size 5. Then 6, 7, and 8 all match. Differences at 9, 10, and 11.
I am not sure what is going on but at these smaller sizes of arrays it may be feasible to calculate the moments manually to see where the errors are.
Without seeing the algorithm, or running the code (yet). I will say that in GregS' code I would be very surprised if you want to round the log2(x) value by coercing to I32. You
almost certainly probably want to round to +Infinity.
With more inspection (no testing) I would also suggest that you add an increment to all of the iteration values in the Snippet of GregS' that you called the solution. The formula is probably 1-based indexing.
There is some discussion in the thread of zero- vs one-based indexing. The errors he reported accounted for that, I think.
You comments about the log coercion are valuable.
You need to compare to 3.g (or another routine that will compute using 1-based indexing). I did make the point that this indexing was 1-based -- as it should be.
Also Darin is right (as always!), the log2(x) result should be rounded up to the next integer, and then all differences are essentially zero for whatever image I use. This is the reason why Lynn was seeing errors for sizes of 5, 9,10,11 etc, but not 4,6,7,8,12 (where the I32 coercion rounded correctly anyway). Sorry for the mistake.
Thank you guys!
In image processing, computer vision and related fields, an image moment is a certain particular weighted average (moment) of the image pixels' intensities, or a function of such moments.
This VI calculates the weighted moment and the centroid of an image (use "IMAQ ImageToArray" to convert an image to an array).
The angle Alpha is in degrees.
Thank you again to all people engaged in this thread for helping make this VI and making it fast
Given the discussion and the (correct) code of GregS in the posts before I think that rounding to the next higher integer has been swapped to the wrong side of the log function (upper left part of the diagram). It should be between log and I32 conversion.