http://imagej.273.s1.nabble.com/duplicate-entries-in-ROI-tp5016700p5016708.html
> On Jun 21, 2016, at 23:28 , Ondřej Šebesta <
[hidden email]> wrote:
>
> Hello Kenneth.
>
> I am recently playing with multipoint selections as well. Today I noticed
> similar behavior with this (see lower) simple macro. It is working as
> expected, but try to comment or delete line 24 - run("Select None"); in the
> function floorArray(); and see the new result in Log window and in the
> image. To me it double the array.length and sometimes draw two points nearby
> themselves.
>
> It looks to me that run("Select None") efficiently delete previous
> multipoint selection. However, when Select None is not called from macro and
> selection is "deselected" by clicking to the image with rectangular
> selection tool activated, it is not enough and coordinates of original
> multipoint selection somehow persist, despite points in the image are
> already hidden. I am not sure if it is a bug or a feature, however it seems
> to make some kind of troubles.
>
> I guess that in your complex plugin calling deselection is sometime ok and
> sometime not, which leads to "unpredictable" doubling of your coordinates.
> And I believe this is somehow related to my problems I tried to describe
> here:
https://list.nih.gov/cgi-bin/wa.exe?A2=ind1606&L=IMAGEJ&F=&S=&P=85495>
> I am curious to know what is printed to the log window with and without line
> 24 for you.
>
> Hope this helps a little.
> Best Regards, Ondrej Sebesta
>
> //open some single channel image first...
> roiManager("Reset");
> setTool("multipoint");
> waitForUser("make at least 3 points");
> roiManager("Add");
> getSelectionCoordinates(Xcoord, Ycoord);
> print("original point coordinates X and Y");
> Array.print(Xcoord);
> Array.print(Ycoord);
> print("\n");
> Xcoord=floorArray(Xcoord);
> Ycoord=floorArray(Ycoord);
> print("floored point coordinates X and Y");
> Array.print(Xcoord);
> Array.print(Ycoord);
> redrawPoints(Xcoord, Ycoord);
> getSelectionCoordinates(Xcoord, Ycoord);
> print("redrawd point coordinates X and Y");
> Array.print(Xcoord);
> Array.print(Ycoord);
> roiManager("Add");
>
> function floorArray(array){
> //try to comment next line and see the difference
> run("Select None");
> for (a=0; a<array.length; a++) {
> array[a]=floor(array[a]);
> }
> return array;
> }
>
> function redrawPoints(xcor, ycor) {
> if (xcor.length==ycor.length) {
> for (x=0; x<xcor.length; x++) {
> setKeyDown("shift");
> makePoint(xcor[x], ycor[x]);
> }
> }
> else exit("not equal length of X and Y coordinates array");
> }
>
>
> ---------- Původní zpráva ----------
> Od: Kenneth Sloan <
[hidden email]>
> Komu:
[hidden email]
> Datum: 20. 6. 2016 22:25:27
> Předmět: duplicate entries in ROI?
>
> "I have a Java plugin that does some fairly complex manipulation of ROI’s.
> This is a data collection program that allows the observer to select
> multiple POINTS (which we tag with a TYPE). The points are selected while
> browsing through a STACK. The plugin re-paints the display on every
> selection, and every movement among slices. Briefly, we want to display
> previously selected points in a restricted range of slices (to provide local
> continuity, but avoid clutter).
>
> At the end of the selection phase, the plugin writes all of the selections
> to a custom .csv file, noting x,y,z,type for each selected point.
>
> All this works just fine.
>
> Except…later analysis of the output file reveals duplicate entries. Exact
> replicas of x,y,z,type. At first, I suspected that the observer was double-
> clicking on points - producing two entries. But, then I found cases where
> many points (at least 5 or more) are duplicated in blocks. That is, we see
> points 1,2,3,4,5,1,2,3,4,5. Again, the x,y,z,type for each of the 5 pairs
> are identical - but there are 5 distinct and widely separated points. The
> duplicates (either single duplicates, or blocks of duplicates - two copies
> of each of several points) seem to always appear next to each other in the
> list of points. I *think* they are all of the same “type”.
>
> For now, I’m satisfied with filtering out duplicates (we are counting and
> locating small particles in a large volume (no…we can’t find the particles
> automatically - we’re at the hairy edge of image quality and this task *
> requires* a trained observer to locate and classify each particle. There are
> as many as 21 different types of particles, based on size and very detailed
> analysis of the shape and texture of each particle. Exact, even very close,
> matches in position are physically impossible.
>
> But, I really need to track down the source of the duplications. Has anyone
> seen this kind of duplication in ROIs? My first suspiscion is some sort of
> race condition or multi-threading error. All of the processing done by my
> code is on detection of a selection or a change in the slice. There is
> considerable massaging of the data every time the current slice changes, and
> also whenever the current “type” of particle changes (we use radio buttons
> to establish the current “type” and then select multiple points of that type
> - the display conventions change whenever the current “type” changes, and
> also when the current slice changes. My first pass through the code will be
> looking for the possibility of duplications happening on these “phase
> changes”. The fact that the duplicates are all of the same “type” seems to
> indicate that the duplicates are created when the “type” is changed (by the
> user, with a radio button). Perhaps there is some nicety that we’ve missed
> on closing out the current ROI and making a different one “current”?
>
> The number of duplicates is quite small, so this is a moderately rare event.
> This argues against duplications happening every time a slice or type
> changes. It may argue for a non-deterministic multi-threading race
> condition. The point is - I don’t think that duplicates are created *every*
> time the use switches from one “type” to another.
>
> All clues gratefully rented.
>
> I’d be happy to share the code with anyone *seriously* interested in
> investigating this - but it’s too big and complex for a casual once-over. It
> ’s probably not terribly *good* code, but I didn’t write it…I’m just the
> lucky guy who gets to maintain it. I confess that I don’t fully understand
> it. I can modify the behavior to a certain degree, but that’s about it. Pity
> me.
>
> --
> Kenneth Sloan
>
[hidden email] <mailto:
[hidden email]>
> Vision is the art of seeing what is invisible to others.
>
>
>
>
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html"
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html