Vectorize subpixel approximation

[ErichZimmer]

Usually, I follow the recommended instructions, but lately I'm running low on time and data. Getting on point, should we vectorize subpixel approximations? I made a quick function that shows some very promising speedup.

https://github.com/OpenPIV/test_robustness/blob/main/notebooks/test_vectorized_find_subpixel_position.ipynb

[ErichZimmer]

With the vectorized approach on the subpixel approximation, I was able to get the signal-to-noise methods vectorized with a markup in speed of up to ~300%. Additionally, I rewrote the vectorized subpixel method and will be issuing a pull request showing all new methods and their respective benefits soon.

[alexlib]

Dear @ErichZimmer I suggest you split the pull request into portions. We could review the subpixel approximation that should work with the existing algorithms as well, right? Now it seems that #208 needs to be reviewed for both correlation issues (robustness, speed, quality control) and this one. Can these be splited?

[ErichZimmer]

Yes, these can be split very easily. For the vectorized functions, they work right out of the box for all vectorized correlation functions. I'll test robustness of the new algorithms on a separate pull request or feature request as soon as I figure out what I keep doing wrong on the calculation of RMS and bias errors. Additionally, I guess I'll have to test them on most of the PIV challenge cases and see where that goes.

[ErichZimmer]

Dear @alexlib , Maybe I'm just a little bit paranoid, but when I compared the vectorized signal to noise and correlation to displacement functions, it started to deviate from the original functions after six significant digits. I looked into it and can't seem to find what is causing it (maybe it's different float types?). Is this an acceptable amount of deviation, or should I try a little harder to get as close to a carbon-copy of the original function's output?

Thanks, ZImmer

[alexlib]

It is okay to test things. Let us see - which branch and which test do you run? When you do pull request, I plan to run it as well and study a bit deeper before pulling, so we should discuss it on the way.

[ErichZimmer]

Here is the repository. Some synthetic images are included under test14 in the examples folder. In the notebooks folder, the test_vectorized_functions and preprocessing_filters notebooks demonstrates the new features along with some testing. Some other minor changes were made that can be seen when using GitHub's comparison page. https://github.com/ErichZimmer/openpiv-python

[alexlib]

I have tested both notebooks and looked at the code, it's nice. Recommend to merge.

[ErichZimmer]

Should we add a 9 point gaussian regression or non-linear gaussian peak estimators? Each have their advantages and disadvantages for certain conditions. Furthermore, they seem pretty simple to implement.

Regards, Erich

[alexlib]

Possible. It is a nice feature. I believe what is more important now is really a simplification and explanation of the user cases, along with examples and speed. Most users will not use all the features and won't be able to test how each feature combines with others. A large set of options is great but only if it is clear when and how to use those in synergy to achieve the desired result. Maybe we need to add the uncertainty measure to be kind of "gross measure" of the PIV process?

[ErichZimmer]

simplification and explanation I agree. Many options and not much explanations. I'll see what I can do on this issue. examples and speed Would more detailed notebooks work? Maybe we should make a nested library of notebooks so it won't be so cluttered? uncertainty measure This would be helpful. Additionally, a thorough investigation should be done on particle density, shape, and size and how preprocessing effects them.

On optimization/speed, I found that the deformation methods are very fast, but the FFT-based cross-correlation can be slow. I haven't figured this out yet, but when using FFTW (PyFFTW wrapper) and comparing it to another software written in c++ (Fluere), OpenPIV can be as much as 5.5 times slower. Both use the FFTW library, but the correlation speed is so different. I just couldn't figure out why.

PS, Sorry for any random opening/closing of issues, as my phone is prone to lagging and user error.

[alexlib]

simplification and explanation I agree. Many options and not much explanations. I'll see what I can do on this issue. examples and speed Would more detailed notebooks work? Maybe we should make a nested library of notebooks so it won't be so cluttered? uncertainty measure This would be helpful. Additionally, a thorough investigation should be done on particle density, shape, and size and how preprocessing effects them.

On optimization/speed, I found that the deformation methods are very fast, but the FFT-based cross-correlation can be slow. I haven't figured this out yet, but when using FFTW (PyFFTW wrapper) and comparing it to another software written in c++ (Fluere), OpenPIV can be as much as 5.5 times slower. Both use the FFTW library, but the correlation speed is so different. I just couldn't figure out why.

PS, Sorry for any random opening/closing of issues, as my phone is prone to lagging and user error.

@ErichZimmer

the problem I have with pyfftw is the installation of fftw library - it will create an enormous amount of support issues.

I suggest to take a look on this: https://pypi.org/project/mkl-fft/ - it seems to be easier to install through pip or conda and we could write some conditional import that falls back to the scipy.fftpack if mkl-fft is not available in the import path.

[ErichZimmer]

On MKL, anaconda/miniconda installs it automatically and numpy/scipy gets an automatic boost. However, I have not looked into Intel MKL features to optimize it for digital cross correlations. For performance on batch processing, the multiprocessing class mostly makes up the speed differences and OpenPIV becomes ~1.8 times slower than PIV softwares written in c++, at least on my "low performance" laptop.

[alexlib]

Thanks for the info. So we need to do profiling and find where our bottlenecks, or think about efficient and simple all platform installation of pyfftw and fftw libraries. Otherwise it is a problem.

[ErichZimmer]

Using intel MKL, the speed of a multipass evaluation is on par with several commercial and c++ softwares, at least for a vector/millisecond scale and small images. I wonder if OpenMP and optimization (and being precompiled) is the reason why PIV softwares written in C++ are so fast, even for larger images.

Settings: preprocessing: none passes: 3 interrogation windows: 64>32>24 overlap: 50% windowing: uniform deformation method: second image deformation algorithm: B-Spline (7x7 sinc for Fluere) deformation degree: 3 (N/A for Fluere) subpixel estimator: 3 point gaussian validation: local median, threshold at 3 Note: validation is done for all passes except the last pass Smoothing: medium/s=0.8 Note: smoothing is done for all passes except the last pass correlation method/zero padding: circular/none

Other: 'standard 1' refers to standard FFT correlation using a single core. 'standard 3' refers to standard FFT correlation using multiprocessing with three cores. PIVview (there are exceptions) and Fluere can't batch process in parallel. Analysis is done over 193 synthetic image pairs. Times are based on completion of the batch processing and averaged over frames and number of vectors. On larger images, OpenPIV python tends to be much slower than the above mentioned PIV softwares. However, this can be mitigated by using the multiprocessing module.

[ErichZimmer]

Here is one more test I just did with the same settings.