Cached FFTs can get very large

As we push towards using full, or closer to Full Res images for stitching on the pi are getting memory issues.

If we are using a full res 3280*2464 image for stitching. Due to padding the FFT is 3280x4928 (half the size of what we may expect due to using rfft2 not fft2). As the FFTs are saved as Complex128, this means that the size per cached FFT is 259MB!

Even if we downsample by a factor of 4 (or use the lowres stream) this is still 16MB per cached image.

As due to break_ties the image is now also cached this brings cache per image to be processes to 283MB or 18MB. Depending on if downsampling.

Only saving the image is: 24MB or 1.5MB.

Suggestion: Caching images only and not FFTs

The Pi crashes trying to stitch full-res images. Taking downsampled images the time to load the jpg off disk is about .3s the time to perform the FFT is .15s.

We did not profile the full process but assuming the only other time consuming part is the is the ifft, and taking the assumption that it is also approximately .15s. Then assuming a "new" image is in ram and overlaps with 3 images:

Nocaching is:

• 0.9s - load old images
• 0.45 - fft old image
• 0.15 - fft new image
• 0.45 - ifft each pair

Total estimated time = 1.95s

Caching images only:

• 0.45 - fft old image
• 0.15 - fft new image
• 0.45 - ifft each pair

Total estimated time = 1.05s

Caching images and FFTs:

• 0.15 - fft new image
• 0.45 - ifft each pair

Total estimated time = .6s

summary

It is probably more complex than this, but I think we should try only caching images in RAM.