Hi Michael, 1 - Your Versatile Wand Tool has exactly the same issue given that it's window is as well not an NonBlockingGenericDialog. First I start by defining a pixel position, then I open the setting window and play with the Tolerance value and then I want to try to change the pixel position. But for this I need to close the setting window and open it again and so on. I had already made the needed change within my local version of ImageJ and even sent you the needed code in private a couple of months ago. But given that these changes will be lost at each update, I would apreciate to have it changed within the source code if possible. 2 - Given that Show All is activated within the ROI Manager, I expect a deleted ROI to disapear from the display upon deletion from the ROI Manager list. Thus I don't see situations where this would not be expected, but you are a greater expert. 3 - I fully agree with your coment on this point, this is why I reported it given that I was as well expecting the slice association to be (only) read from a variable in the Roi object. But with such a formating of the ROI name, it is even impossible to dissociate the ROI from the corresponding slice association. Nevertheless I can fully live with this and the workarounds could be ROI-CCC-XXXX-YYYY or even CCC-XXXX-YYYY given that I don't have such a huge list of elements. Kindest regards, Philippe
----- Mail original ----- De: "Michael Schmid" <[email protected]> À: "imagej" <[email protected]> Envoyé: Jeudi 20 Novembre 2025 16:28:42 Objet: Re: A couple of updates requests Hi Philippe, some kind of workaround for (1): The Versatile Wand Tool https://wsr.imagej.net/ij/plugins/versatile-wand-tool/index.html has preview of the roi generated if you had clicked on a position before opening the options. (This is a feature that Wayne had invented and implemented, not mine.) Is this the desired behavior?It does not need a NonBlockingGenericDialog. Concerning (2), deselecting a roi when it is deleted in the ROI Manager: In principle, the roi of an image and the rois in the ROI Manager are two separate things, not necessarily related. So I am not sure whether deselecting the roi upon deletion in the ROI manager would always be the expected behavior. Concerning (3), roi names like 0001-0069-0102: This is exactly how the ROI Manager labels its rois. There, "0001" is the slice number, and the following numbers are the y and x coordinates of the center of the bounding box. I don't know, however, why the slice association is read from the roi number; it is stored as a variable in the Roi object anyhow. Michael ________________________________________________________________ On 20.11.25 15:48, CARL Philippe (LBP) wrote: > Dear all, > I would have a couple of small update requests, namelly: > 1 - Make the Wand Tool setting window as a NonBlockingGenericDialog. > The ROI obtained through a Wand Tool selection highly depends both on the set > Tolerance value as well as on the selected pixel position and intensity. > Once a given pixel selected, it is possible to preview the change of ROI by > opening the Wand Tool setting window and changing the Tolerance value. > But given that the setting window is a regular GenericDialog it isn't > possible to modify the initial pixel position without closing the window > which is a hassel if you want to make a back and forth between the pixel > positrion and Tolerance value. > 2 - Get rid of the display of a ROI when it is deleted from the ROI Manager > list and Show All is activated. > When I have a bunch of ROIs within the ROI Manager with Show All activated > and delete a given ROI from this list, it really disapears from the display > only if I select another ROI from the list or activate/desactivate the Show > All feature, as I would expect that it disapears right away after I deleted > it. > 3 - Is this a bug or a feature? > I made a macro to rename a whole bunch of ROIs within ROI Manager files in > the following form: CCCC-XXXX-YYYY > with CCCC a counter attributed to a given ROI (i.e 1, 2, 3...) with a pading > of 4, > XXXX the x position of the centroid of the given ROI with a pading of 4 and > YYYY the y position of the centroid of the given ROI with a pading of 4. > With this formatting, I found out that the position of a given ROI was then > attributed to the slice number which is similar of doing a > "RoiManager.setPosition(CCCC);". > Is this a feature or a bug? > For information, in the case I don't format the ROI name exactly this way > (i.e. if I just use a pading of 3 for example) this is not hapenning. > Thanks a lot for your thoughts and replies on this and have a nice day. > My best regards, > Philippe > > Philippe CARL > Laboratoire de Bioimagerie et Pathologies > UMR 7021 CNRS - Université de Strasbourg > Faculté de Pharmacie > 74 route du Rhin > 67401 ILLKIRCH > Tel : +33(0)3 68 85 41 41 > > -- > 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
