Thank you for the explanations. The scales being different especially makes
sense. We do a lot of kymograms where X is spatial and Y is temporal, so this
definitely makes sense.
I'm a big fan of keeping things 100% backwards compatible. I found it easy
enough to solve my problem with this code. I haven't tried it yet called from
a routine handling a lot of biological images in batch mode, but it seems to
work. I was mostly concerned that if flipping horizontally didn't need to be
done in a duplicate window, would this revert later.
I'm sure there's a simpler way to do this that I haven't thought of, but here's
the code...
/******************************************************************
* function randomizeROI();
* The goal of this function is to change a region of interest of an image
* so that the density of features will be the same as the original but none
* will colocalize. This can be used as a statistical test of whether a
colocalization
* result is due to biologically determined colocalization of features or
random overlap.
* The first step is rotation by 90 degrees. Because central features will
remain
* central, the left 2/3 of the ROI is then flipped horizontally so that central
* features are flipped to the perimeter.
* This function works exclusively on a single channel image. It may work on a
multi-
* channel image in grayscale or color mode, not composite mode, but was not
tested.
* The ROI must be in the ROI manager and passed to the function.
* This function works faster with setBatchMode(true) or (hide);
*****************************************************************/
function randomizeROI(ROIMangerIndex) {
run("Set Measurements...", "area standard min centroid center bounding fit
display redirect=None decimal=2");
roiManager("Select", ROIMangerIndex);
run("Measure");
xc = getResult("X", nResults-1);
yc = getResult("Y", nResults-1);
toUnscaled(xc, yc);
diameter = maxOf(getResult("Width", nResults-1), getResult("Height",
nResults-1));
toUnscaled(diameter);
radius = diameter / 2;
makeOval(xc-radius, yc-radius, diameter, diameter);
pasteWindow = getImageID;
setPasteMode("Copy");
run("Copy");
run("Duplicate...", "title=temprotate");
run("Rotate 90 Degrees Left"); // rotation alone does not work because the
center stays the same
makeRectangle(0,0,(2*diameter/3), diameter);
run("Flip Horizontally");
makeOval(0, 0, diameter, diameter);
run("Copy");
selectImage(pasteWindow);
run("Paste");
run("Select None");
close("temprotate");
} // end randomizeROI(ROIMangerIndex)
Best regards,
Michael Cammer, Sr Research Scientist, DART Microscopy Laboratory
NYU Langone Health, New York, NY 10016
[email protected]<mailto:[email protected]>
http://nyulmc.org/micros http://microscopynotes.com/
Cell voice (no text) 1-914-309-3270
Office 1-646-501-0567
________________________________
From: Michael Schmid <[email protected]>
Sent: Monday, July 22, 2024 1:19:21 PM
To: [email protected]
Subject: Re: rotating ROIs
[EXTERNAL]
Hi Michael,
one reason for the different handling of Image>Transform>Rotate 90°...
and flipping might be the following:
Rotation by 90° needs to change the image size (switch the image
width&height) for non-square images. Also the spatial calibration needs
to be changed if the x&y scales are different.
Flipping operations (as well as "Translate") leave the image size unchanged.
Thus, for the whole image, these are quite different operations.
Nevertheless, if I look at the code, flipping and 90° rotations are in
the same class, thus it would not be too difficult to change this, by
having a 'roi mode' where the 90° rotations are handled in the same
branch as the flipping.
I am not sure whether there are any macros around that rely on flipping
always affecting the full image irrespective of any Roi; if so, changing
the behavior would break these macros.
---
BTW, one of the not so nice things that also noticed in this respect:
For non-rectangular ROIs, "Flip Horizontally", "Flip Vertically", and
"Translate" are restricted to the bounding box, not the actual roi.
Rotation by arbitrary angle honors the actual Roi.
(I think that this could be fixed by adding a 'SUPPORTS_MASKING' flag.)
Another thing that I noticed: I would consider it clearer to have
Image>Transform>Translate not translating the Overlay when applied to a Roi.
Michael
________________________________________________________________
On 22.07.24 16:59, Cammer, Michael wrote:
> I was curious why the behavior varies for different types of ROI rotations.
>
>
> For instance, this code operates exclusively on the ROI.
>
>
> makeOval(81, 65, 82, 82);
> run("Flip Horizontally");
> run("Flip Vertically");
>
> However, this code rotates the entire image.
>
> makeOval(81, 65, 82, 82);
> run("Rotate 90 Degrees Right");
>
> I need to rotate the ROI can can do this by duplicating it, rotating it, and
> pasting it back into the original. Also by creating an ROI that covers the
> left 2/3 of the field and flipping it horizontally because central features
> don't move when rotated. The goal is to create a "random" distribution with
> the same density at the real sample. When coding this, I found the
> differences and was curious about them.
>
> Thank you.
>
>
>
> Michael Cammer, Sr Research Scientist, DART Microscopy Laboratory
>
> NYU Langone Health, New York, NY 10016
>
> [email protected]<mailto:[email protected]>
>
> http://nyulmc.org/micros http://microscopynotes.com/
>
> Cell voice (no text) 1-914-309-3270
>
> Office 1-646-501-0567
>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
