When cropping a .mspec or cone catch image before applying Gaussian or AcuityView acuity control, users will realise that the resulting image of an individually blurred ROI from such a cropped image is not numerically identical to the result of the same ROI processed with Gaussian acuity control from the uncropped image. How so? After all, the ROI and the size standard are the same! This is because the change in image size interferes with the image rescaling after applying the Gaussian/Fourier blur. The image is smaller, yet the standard is still the same size, leading to a different ratio between the image’s angular width and the standard’s scale. As a result, the ROI in question will be rescaled differently between the cropped and the uncropped image, even though it is still the same size.
To avoid any issues with this, we recommend not cropping an image before analysing but rather analysing any ROIs in question individually using the ROI manager in the toolbox. However, there are reasons why the users might want to crop an image or, even more importantly, have been using cropping in images in the past, e.g. to reduce processing times in large datasets if only a certain area of the image is of interest.
To correct this issue when analysing cropped images, you must change the ‘Gaussian_Acuity_Control.ijm’ or ‘Acuity_view.ijm’ scripts and have the cropped dimensions (‘h’ and ‘w’) of your cropped images replaced with the original ones in L36-37. Usually, all images in a given dataset are taken with the same settings, so these values could be hard coded e.g.:
w = getWidth();
h = getHeight();
changes to:
w = 3560
h = 3200
More elegant solutions (i.e., in a batch script using image cropping) would have the original dimensions read and saved into a .txt file and then read back into the acuity script.
Note: This issue is only relevant for users of AcuityView using its implementation in QCPA, as the rescaling of the images is a functionality not supplied with the R package.