Annotation downscaling when transferring to another image with a different pixel size

When I try to transfer an annotation from one viewer to the next the annotation shrinks to about half the original size. The second viewers image does have seem to have about half the pixel size as the original image, this also means it has twice the amount of pixels. Thats what i believe is causing the problem, but not sure how to fix it. I’ve tried changing the pixel size, but that just changes the overall number of pixels in the image and therefore doesn’t have an effect.

Any help with this would be much appreciated.

I am not sure if there is a way to scale annotations, @melvingelbard @petebankhead or @Research_Associate may have better idea.

One work around would be to resize the image that has higher resolution (smaller pixel values) to match the resolution of the low resolution image before loading in QuPath.

What type of images are you working with ? Additional details may help !

1 Like

If you only want the size of the annotation, one trick would be to set the pixel size in the destination to the same as the original image, and then fix it afterwards. I see you already tried. Oops. Although I am not clear on how you tried it. Did you change the pixel size prior to creating the annotation you want to transfer? Did you change the pixel size in the destination image prior to transferring, after transferring? There are many options.

It should not have any effect on the number of pixels in the image.

Otherwise, you can try overlaying the two images and figure out the affine transform (which includes the resizing) through the Interactive Image Alignment. Once you have that, you can use scripts to transfer objects around, which may be better if the images are from sequential slices or similar, as the location would be preserved.


The transfer scripts can definitely work between images with different pixel sizes. Our project involved one image with a pixel size of 50 microns and another with a pixel size of 0.2 microns.

If you want to edit the magnification during the Interactive Alignment, the two numbers to change are the two that start out as 1.0000
Top left and middle bottom in the image.

1 Like

Thank you for the help on this. I will try the transfer scripts now. I changed the destination pixel size after drawing the annotation on the original image, but prior to transferring it. You are right it does not change the number of pixels, it changes the over all size of the image. This means the image is twice the size it should be. So when i transfer the annotation it is still half the size it should be.

I think I have aligned the images correctly now. Is there a need to save the overlay once I’ve edited it manually, or can I just close the window and the images should be in the correct alignment? Also, what script should I run to transfer the annotations?

I get an error when trying to auto-align. It says that results did not converge. Also, what are the units for the pixel size in the auto align area of the image overlay alignment? I assume I want the area annotations alignment type? Alternatively, I can just do it manually with the affine transform section, but I’m confused on how to save that change. Could I then just transfer last annotation using shift E to bring my annotations over individually, or would I need to run a script?

You need the affine transformation matrix. You may also have problems converging the auto-alignment if you do not get things pretty close to begin with. It does not tolerate incredibly large differences, so if the sizes are very different, you may need to start with the right magnification settings as described above.

Which script you use would depend on how you want to transfer the objects. Pete’s original script has you add the exact text manually for both the affine transform and the file names, which might be the easiest option if you just want to do the transfer once or twice. The other scripts in my post were for more complex uses, like transferring hundreds of objects between several images, and require more setup.

For Pete’s scripts, see the attribution in the script in the second post:

Script base on: Interactive image alignment
and adjusted thanks to Pete’s script: Writing objects to another .qpdata file in the project

Units are in downsample, larger will converge faster, if they can converge at all. Depending on how similar your tissue slices are, you may not be able to get things to converge well, and might need to explore other options like non-rigid alignment. Sara wrote up a nice description of that here.


Thank you very much. This worked perfectly. Your help is much appreciated.



I am trying to transfer an annotation in QuPath-0.2.3. The source and destination images have different pixel sizes. Is the script below (updated for 0.2.0) + interactive image alignment still the recommended way to do to this?

I notice there is also an option when setting pixel size with an annotation selected to Enter selected ROI area in μm^2. For a JTS-powered geometry annotation, would this need to be the desired area calculated after the holes are filled? How would it work?

Hope this makes sense,


Pinging @petebankhead (I hate to do this, sorry!). Do you have any suggestions?

In hindsight, this probably deserved to be split, as this topic already has a post marked as the solution.

Thank you :slight_smile:

Have you tried this script?

You may need to adjust the alignmentType and otherFileName at the top of the script, and whether it grabs detection objects or annotation objects in the GatherObjects subfunction.


Sorry @camlloyd, having a fairly crazy week!

Not sure about ‘recommended’, but I don’t think there’s a better option yet :slight_smile:

To correct for pixel size only (and worry about shifts/rotations later), I guess you could hard-code the matrix to do a scaling based on the ratio of the pixel sizes for both images… which I assume will be a constant:

def matrix = [
        scale, 0, 0,
        0, scale, 0

(This is completely untested…)

From memory, it calculates the area of the ROI in pixels (holes shouldn’t contribute) and uses this in combination with the input area and the assumption that pixels are ‘square’ to set the pixel width & height.

Always worth checking to see if it does what’s expected though.

My memory of my own scripts is foggy – I’d trust @smcardle to have a lot more relevant insight than me when it comes to this.

1 Like