http://imagej.273.s1.nabble.com/duplicate-entries-in-ROI-tp5016700p5016716.html
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…
> 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