Acuity

[thomased]

Very rough implementation of AcuityView algorithm. Feel free to jump in & hack at it if/as you like.

tiger <- getimg(system.file("testdata/images/tiger.png", package = "pavo"))
tiger_acuity <- procimg(tiger, acuity = c(60, 8, 0.2))

par(mfrow=c(1,2))
plot(tiger)
plot(tiger_acuity)

Still todo:

• [ ] Refactor/speed-up.
• [x] Remove requirement of square images with dimensions a power of 2. Don't understand FFT quite well enough to have an intuitive solution off-hand. Some old documentation suggests ImageMagick used to pad an image with garbage to square it out, apply the transform, then crop it back down to the original size after. Might be an option.
• [x] Argument names & structure. Currently uses a vector to define the three required arguments via acuity = c(). Tidy but a bit unconventional — should each value be a separate argument in procimg() instead? (Answer: Yes, the vector thing was a bad idea)
• [x] Add tests.
• [x] Run it all by Eleanor for her ok.

[Bisaloo]

There seems to be an artifact (pink from the flower) on the right side on this image. Does it matter?

[thomased]

There seems to be an artifact (pink from the flower) on the right side on this image. Does it matter?

Good question. AcuityView does the same (below). Ideally no of course, but it's a very compressed low-res image — could be related. But not sure off the top of my head.

[Bisaloo]

From my (very distant) memories about FFT, it has to do with boundary conditions when you do the round trip FFT/IFFT. I don't know if it can't be adjusted. I don't even know if it will impact downstream analyses in any way.

[thomased]

Just as a note-to-self. To get the algorithm working with rectangular images of arbitrary size I think we need to zero-pad. That's basically how ImageMagick does it (below), but unfortunately this doesn't seem to be implemented in magick yet so we'd have to roll-our-own. I've got a crap version working, still figuring out the details.

From https://legacy.imagemagick.org/Usage/fourier/

Using FFT/IFT In ImageMagick

Implementation Notes

ImageMagick makes use of the FFTW, Discrete Fourier Transform Library which requires images to be converted to and from floating point values (complex numbers), and was first implemented in IM version 6.5.4-3. To make it work as people generally expect for images, any non-square image or one with an odd dimension will be padded (using Virtual Pixels to be square of the maximum width or height of the image. To allow for proper centering of the 'FFT origin' in the center of the image, it is also forced to have an even (multiple of 2) dimensions. The consequence of this is that after applying the Inverse Fourier Transform, the image will need to be cropped back to its original dimensions to remove the padding.

[Bisaloo]

Jeroen, the magick's maintainer, mentioned multiple times that he's open to adding new features from ImageMagick in magick. It's just that he isn't sure what is useful to users. You could try opening an issue and see how it goes.

[thomased]

Ah cool — I'll keep it in mind. I might just pin down exactly what I need first.

I may have been barking up the wrong tree anyway. The fft -> ifft seems to work fine on rectangular images out of the box, but calculating & applying the MTF (blur matrix) is the issue (I think). In which case generalising that may be all that's required, which shouldn't be too tricky...