Posted by
Schebique on
Jun 22, 2016; 8:36am
URL: http://imagej.273.s1.nabble.com/duplicate-entries-in-ROI-tp5016700p5016711.html
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