From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
The output of IMAQ correlate is completely wrong
Shown in the attached picture is the output of IMAQ correlate (supposedly the normalized cross correlation), the output of my handmade function to calculate the normalized cross correlation, and the output of MATLAB normalized cross correlation.
Yours is the one that is completely wrong. This is not a dynamic range scaling issue. Your output is mathematically incorrect.
-root
Here's a link to a fast normalized cross correlation written by GregS:
http://forums.ni.com/ni/attachments/ni/200/22723/1/NormXCorr2D.llb
Not surprisingly, it agrees with the MATLAB normalized cross correlation as well.
-root
perhaps this is more clear.You've had four days to verify that your function is returning a bad result. I provided mathematical proof using your own programming language and verified the result with two independent sources. Would you like to borrow my copy of Matlab or something?
-root
ok, thanks. we'll just code up a dll to do the normalization with sum tables like GregS illustrates in his example (linked above). I'm using normalized cross correlation to compute a fast and dirty sparse optical flow map for motion detection in scenes with a fair amount of texture.
Why don't you guys include 2D wavelet processing in the vision toolkit - you've got it in signal processing, but no one wants to have to convert images to arrays on the block diagram because of the potential performance hit. I also notice that there are some simple functions that you could include. The one that gets me is that I don’t see a simple min/max function for images. If you want to know the min or max value in an image, you have to use a function that computes the mean and standard deviation as well, or you compute a histogram. Isn't it much slower to compute all that jazz than to simply compute a min/max similar to the function on the array palette? I need to return a min/max much more often than compute the mean or standard deviation, you know?
Another example of something that seems like it is missing is that for the IMAQ operators (addition subtraction etc...) there's no mask input. That's a real killer. What if I just want to add a constant to a region of an image? It takes me several operations because I don't see a way to just do it directly.
I know that labview is kind of geared towards 1-D signal processing and that it really kicks a$$ at that. I know it's not intended to replace mid-level languages as far as raw speed, because that's not really feasible with a high level language. But I think that Labview has the potential to completely displace Matlab as the language of choice for serious computer vision prototyping. I think that it could really be a phenomenal image processing and computer vision prototyping language.
You've got some more work to do for that to happen, though. The documentation tends to leave the user wondering about details of function operation. You need a little more functionality in the Vision add on (at the least include image pointer versions of regular labview array functions and 2d signal processing functions). You’ve got to go back through the IMAQ functions and make sure that they all behave according to the same conventions (example: some IMAQ functions coerce a mismatched image dst type to match input, some decide to return an error instead. Grrrrr.)
As far as bugs, everything has bugs in it. Big deal. Programming work is always 99% debugging. What I notice on the boards is that support engineers have a subconscious tendency to be dismissive of posts that cry bug. I can understand that most of the time it’s because users mistake a bug in their code for one in yours. But the last thing NI wants to do is to ignore a bug that’s really there. It gives the wrong impression.
Cheers
-root
Why don't you guys include 2D wavelet processing in the vision toolkit - you've got it in signal processing, but no one wants to have to convert images to arrays on the block diagram because of the potential performance hit.
While I'd also like wavelet processing for images (at the moment I convert back and forth), I'm not sure including them in the vision toolkit is the right approach - this will simply create yet another set of routines for the same functions. This is already the case with, for example, FFT, convolution and correlation, and the functionality and use is slightly different with (as seen above) different results - there's often also different code again for MathScript, all of which further increases the likelihood of bugs.
My suggestion is to expand the scope of the "In Place Element Structure" to perform a "memory-less" conversion between Image and Array. Then it would be simple to include any math routine (I've used Min/Max,Sqrt, Wavelets among many others) which are unavailable in the vision module.
The main problem I can envisage with this approach would be the extra information (border pixels) which are part of Images - for most use cases it would probably be ok to retain these (i.e. the array is larger than the image, though perhaps there could be an option as to whether they are mirrored or zero etc. RGB images would provide an array of U32/64, but even better might be a cluster of arrays for each colour plane.
Cheers ~ Greg
