Autoscale the affine transform when viewer and overlay images have different pixel sizes.

[zindy]

Hello,

this pull request is for calculating a scaling factor between viewer and overlay images if their pixel size is different, and apply it to the transform matrix.

This issue (aligning images with different pixel sizes) was discussed on the forum:
https://forum.image.sc/t/align-tool-difference-in-pixel-size-for-the-fixed-and-moving-images-is-not-accounted-for/95973

Scaling can occur when a new overlay is selected and when the reset button is pressed. The new code handles both scenarios.

Cheers,
Egor

[petebankhead]

I agree that automatically fixing the scales would be really useful and important. I haven't tried running it yet, but have added some comments from reading the code - please let me know if you'd like to update your PRs, otherwise one of us will look into reviving this extension soon and can use them instead for inspiration.

[zindy]

@petebankhead

please let me know if you'd like to update your PRs, otherwise one of us will look into reviving this extension soon and can use them instead for inspiration.

I will update this particular PR because I would consider it a "bug" that needs fixing.

Regarding the other two PRs clogging the queue:

• Replaced the Image selection dialog with a searchable ListSelectionView #8 is a "Nice to have" (IMHO) because it homogenises the way project entries are selected across QuPath
• Add a propagate button to copy the (warped) contours from the template image to the selected overlay one #7 is the one I'm the least happy with because it only answers part of the question "what do you want to apply the transform matrix to". My PR addresses "I want to transfer the contours from the fixed image to the overlay". But in the past we've also had "combine the all the channels into a new project entry" and I've been experimenting with "apply the transform matrix to the synchronised viewer that corresponds to the overlay" (a mouthful, I know), which potentially could be even more intuitive than the way NDP.View does it with its two crosses.

So to answer your question: I wouldn't mind getting this "scaling bug" PR merged when you're happy with the code. Then definitely use the other two PRs for inspiration if they help you in any way.

Cheers,
Egor