Posted by
Kenneth Sloan-2 on
Jun 20, 2016; 8:09pm
URL: http://imagej.273.s1.nabble.com/duplicate-entries-in-ROI-tp5016700.html
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