Posted by
Ghislain Bonamy on
May 12, 2009; 10:46pm
URL: http://imagej.273.s1.nabble.com/Convert-a-set-of-points-into-an-ROI-tp3692520p3692526.html
Quick follow up:
Does anyone have an understanding of what the different type of ROI actually correspond to? I think Polygon, line, point are easy to figure out what they are. Some other flavors such as polyline etc. are not as easy to understand.
Karsten,
Thanks for the info. I actually was aware of the possibility of doing something like that, but this is for a high content system where of millions of images are generated. ImageJ may not be fast enough to run this. At this point generating a tool for line tracing of a closed set (like the one I have uploaded), should be fairly easy and hopefully quick. In addition it would allow to avoid distorting the ROI that were used for the data analysis by adding an opening operation.
If anyone has code available to do this great!
Curtis,
Thanks for the long and detailed answer. I was planning to add this line tracing algorithm inside loci.plugins.util.? If this is OK with you. Perhaps you have a suggested Package/Class name? I have already though a bit to the case scenario you proposed. The way I intend to solve this is to check for points which are across and then diagonals. In addition, for the first point, I will force the trace to be clockwise (only check for pixels that are right, top, bottom, right-top diag, right-bottom diag) and force to start at the upper left corner of the shape. Finally, I would erased the points that were already used so that I would not trace backwards.
A more problematic event would be:
010
111
000
However, I am pretty sure that this would never occur. Since it would be represented by:
010
101
000
For the code, I plan to use List<Point> to store the initial coordinate and move them one by one into a Vector<Point> (corresponding to the Polygone calculated). Note: List.contains(currentPoint) works correctly, even if currentPoint is not the same object as the one entered. Let me know if you think the point structure is not ideal, or anything else is not ideal. Once this is written perhaps someone can see if it is optimized?
For the format of the file, I have elected to output it this way (in a convoluted table of coordinates). If you have some suggestions as to the format, perhaps you could show me what you think would be a better format. Currently, the software (Acapella) outputs a list of X-coordinates Y-Coordinates and a list of objects boundaries (each objects has several pixels). So I have to map each XYCoordinateID to an ObjectID. For compactness, I have elected to put all the coordinates for each objects on a same line (thereby avoiding to repat the ObjectID X times, as well as all the other info I want to fit).Unfortunately, the current version does not output an actual ROI file. So I had to generate my own file. I can change the format any way I want. I also intend to add in this file, the ParentObjectType (ex. Nuclei, cytoplasm, etc.), ParentID and ObjectType. In addition to save space, I would have these files added to a zip archive with a directory structure reflecting: field#, Stack#, Time point#). The other advantage is that I can store all of my objects Features in a file with a similar structure. This being said, I am amendable to adopt an alternate solution if you have some other suggestions. I would also generate for bioformats a fileReader to read these ROI. Perhaps we can take this off-line if necessary.