This is the first time I am contributing to an open access project, so let me know if anything I do is wrong.
I am a PhD working in the field of Scanning Probe Microscopy, therefore I work mainly with images and skimage is of big help for my data analysis. One of our routine use FindTransformECC from OpenCV, which is the only OpenCV function I use so far. So, I decided to rewrite it without using OpenCV.
I was able to build the package from the source, and adding my files to the built package, I am able to run my function. (I don’t understand why my files are not present in the built version even if I add them to the source before building)
Could any one guide me to the next step, and what would be missing from my initial commits before asking for a Pull Request?
Hey @CoilM, thanks for reaching out and welcome! Glad you figured out the build toolchain!
Before we ask contributors to invest a lot of work, we usually try to decide whether new functionality is a good fit for scikit-image. The algorithm being already included in OpenCV is a good sign that it is a relevant and useful tool! Though, I am not familiar with ECC but at a first glance it seems basically like AffineTransform.estimate(src, dst) only that it works for already transformed images and not with source and destination coordinates? Since you are probably somewhat more knowledgeable on this topic , I am curious about more context on this algorithm. E.g. are there alternatives wich are worse / better in some cases?
The code itself looks easily ready to be included in a pull request, you even got a gallery example already! If you already want to go ahead, feel welcome to create a PR, you can put in in draft status if you want to signal that it’s ongoing work. If we decide to include it (I think that’s likely) we will do a few passes over the code, add tests and docstrings and align the API with the rest of scikit-image.
You probably need to add the files explicitly to the meson.build in the subpackages directory.
According to what I know about the ECC method (and I am in no way an expert! I just learned about it as a tool for my research) there is two main advantage to it compared to something like AffineTransform.estimate:
It also works for homographies, which are more general than affine transformation.
Since it works on the derivative of the images and not the images themselves it is less sensitive to change in the contrast/brightness of the image (which is the reason we started using it in the first place, in SPM measurements it is often common to have contrast variation from one image to the other).
“although it is a nonlinear function of the parameters, the iterative scheme we are going to develop for the optimization problem will turn out to be linear, thus requiring reduced computational complexity”
and
“Despite the resemblance of our final algorithm to well-known variants of the Lucas-Kanade alignment method which take lighting changes into account [10], [19], its performance, as we are going to see, is notably superior”
I’ll create the PR then and see how it goes from there
, I am curious about more context on this algorithm. E.g. are there alternatives wich are worse / better in some cases?