duplicate entries in ROI?

[Kenneth Sloan-2]

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

[Schebique]

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

[Kenneth Sloan-2]

Thanks - I’m traveling all day today, but will attempt to test…tomorrow.
--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

> 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

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Rasband, Wayne (NIH/NIMH) [E]]

> On Jun 21, 2016, at 5:28 PM, 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.

Hi Ondrej,

Your macro works as expected for me. The array length is doubled when you remove run("Select None”) because the redrawPoints() method then adds the points to the existing selection. You can avoid the doubling by changing the redrawPoints() method to

   function redrawPoints2(xcor, ycor) {
      makeSelection("point", xcor, ycor);
   }

This change also avoids a potential race condition caused by deselecting by clicking on the image.

-wayne

>  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

[Schebique]

Dear Wayne,

thank you, you are right, of course. I forgot about makeSelection
possibility. It seems I should not post anything at the evening without
morning control :)
I do not know the code of Kenneths plugin, but I still guess this mess may
somehow be an issue, however, rarely called as mentioned Kenneth).

Best regards Ondrej.


---------- Původní zpráva ----------
Od: Rasband, Wayne (NIH/NIMH) [E] <[hidden email]>
Komu: [hidden email]
Datum: 22. 6. 2016 5:28:10
Předmět: Re: duplicate entries in ROI?

"> On Jun 21, 2016, at 5:28 PM, 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.

Hi Ondrej,

Your macro works as expected for me. The array length is doubled when you
remove run("Select None”) because the redrawPoints() method then adds the
points to the existing selection. You can avoid the doubling by changing the
redrawPoints() method to

function redrawPoints2(xcor, ycor) {
makeSelection("point", xcor, ycor);
}

This change also avoids a potential race condition caused by deselecting by
clicking on the image.

-wayne


> 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

[Kenneth Sloan-2]

Finally home, and recovering from a 20 hour travel day.  I suspect that there
are enough clues here for me to repair my Java code.  Tomorrow…

Thanks very much for the assistance.

—
Kenneth Sloan
[hidden email] <mailto:[hidden email]>
Vision is the art of seeing what is invisible to others.

> On Jun 22, 2016, at 03:49, Ondřej Šebesta <[hidden email]> wrote:
>
> Dear Wayne,
>
> thank you, you are right, of course. I forgot about makeSelection
> possibility. It seems I should not post anything at the evening without
> morning control :)
> I do not know the code of Kenneths plugin, but I still guess this mess may
> somehow be an issue, however, rarely called as mentioned Kenneth).
>
> Best regards Ondrej.
>
>
> ---------- Původní zpráva ----------
> Od: Rasband, Wayne (NIH/NIMH) [E] <[hidden email]>
> Komu: [hidden email]
> Datum: 22. 6. 2016 5:28:10
> Předmět: Re: duplicate entries in ROI?
>
> "> On Jun 21, 2016, at 5:28 PM, 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.
>
> Hi Ondrej,
>
> Your macro works as expected for me. The array length is doubled when you
> remove run("Select None”) because the redrawPoints() method then adds the
> points to the existing selection. You can avoid the doubling by changing the
> redrawPoints() method to
>
> function redrawPoints2(xcor, ycor) {
> makeSelection("point", xcor, ycor);
> }
>
> This change also avoids a potential race condition caused by deselecting by
> clicking on the image.
>
> -wayne
>
>
>> 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

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html