In this project, we were responsible for aligning three images, all taken in a different channel (r, g, and b) and aligning/stacking them to display one full color image. My original approach was to iterate 15 pixels in both directions for both the x and y axes, with a pyramid recursion if the image size was larger than 512 by 512, and align images based on the inner 2/3ds of the image. However, this was way too slow: np.roll and calculating the sums of squared deviations for the final few cases with huge array lengths took too long, and ran in about three minutes. My final implementation works like this: if the image is less than 1024 by 1024, search 25 pixels in either direction. If the image is larger than that, scale down by 0.5, and only search 5 "pixels" left and right in the larger cases when you propagate back up. I found that in the minimal scaled down case (image is shrunk to 1024 by 1024) the alignment was already very accurate, and I didn't need to search very much in the scaled up places to align the image correctly, mainly just small tweaks. This sped up my program to around a 40 second runtime. One picture that was problematic was emir.tif. While my algorithm did end up aligning it, emir didn't look as good as most of the other pictures. The reason for this was that when I looked at the picture, the intensities didn't match; for some channels, the image was overall brighter than other channels. This means that the sum of squared deviations algorithm would calculate pixels to be off even when they are similar (because the intensities don't match). To fix this, I would've preprocessed every channel image to have matching intensities with histogram equalization, but doing so made my algorithm run too slowly for .tif images.
First list is r alignment, second list is g alignment.