ROI Manager 'losing' selection

I’m running into a problem keeping an ROI from the Manager selected, when using a macro. It seems to be related to the “Update” command. Hopefully someone can tell me the fix.

The workflow is to Open ImageJ (1.52k), and a stored set of ROIs, then start a macro containing this simple coding:

//Getting set up for the session
waitForUser(“Open a JPEG image if there is not one open”);
run(“Duplicate…”, " ");
//Preparing area to be measured
waitForUser(“EITHER\n Place an existing ROI\n \n OR\n Create ROI and send to the ROI Manager (t)\n - Rename it”);
setBackgroundColor(0, 0, 0);
run(“Clear Outside”);

If a new ROI is created, there is no problem, the macro moves through the next steps. However, if an existing ROI is chosen, the message ‘Exactly one item in the list must be selected’ is generated at the “Update” step, and the originally selected ROI is no longer selected in the Manager. Why?

Would anyone have a solution for how to handle this?

Hi Bethany!

What do you want to achieve with the roiManager(“Update”); command? It changes the shape of the ROI to what you have currently selected on
Why do you run run(“Crop”); before you run roiManager(“Update”);? I think switching these two could fix your problem.
Right now the macro depends on the user to select the ROI, then crops the image and changes the active window to the image, then it tries to update the ROI in the ROI manager, but the selection of the ROI there is not “recent” anymore. Whenever there is a command between a selection and using that selection, there’s a risk that selection is lost.

You could make your code more rubust to this problem by adding commands where you specifically select the ROI.

Hi Terhai,

Thanks for your insight - it was a help, and given the coding provided, how and why the ROI gets ‘lost’ is logical. Switching the order of commands makes perfect sense, but oddly the message is still generated. Maybe the problem (or safety net?) is that previously-saved ROIs cannot be directly overwritten? The stumbling block has turned out to be a good thing, as I belatedly realized that overwriting the original ROI co-ordinates was not desirable in this particular case because at the end of this routine all ROIs are saved…but the original ROIs will also be needed in another routine.

As a result, the approach has been changed to have the user select the stored ROI, send it back to the ROI Manager as a new ROI, rename it, then crop the image and update the newest ROI (this works fine). There will then be a correctly-placed ROI for each version of the image. There are a series of steps beyond this coding which modify the ROI in the cropped image a couple of different ways, as well as a need to consult the original ROI in the uncropped image in the last stages of the process.

1 Like

Hi Bethany,

glad I could help. Your solution sounds solid :slight_smile:

Good luck with your project,