Dear support,
Is-it possible to load or save ROI in .roi (ImageJ ROI format) with Icy. I see also other known format like WKT (python) for ROI. What about also .3Droi fromThomas Boudier for 3D ROI ?
Is there any possibilty to draw scatterplot in Icy also considering the ROI ?
Thanks. Mathieu Fallet
Dear @mfallet,
At least i know you can import classic .roi format using the “Import ROI from ImageJ” plugin in Icy.
I don’t think we import WKT nor 3Droi from @ThomasBoudier but he probably knows better than me about that point specifically 
It’s possible to have (basic) Scatter Plot representation of ROI using the ROI Statistics plugin in Icy by clinking on the Chart icon:
Hope that is enough for your needs though as it’s still quite basic.
Best,
– Stephane
Hi @mfallet ,
The 3DRoi format is quite specific to 3D Manager, as when it started it was the only 3D Roi around.
Actually the format is quite simple as you can see when you unzip the file :
X Y Z value
I will be happy to discuss with @Stephane to help import this format to ICY.
Best,
Thomas
Hi @ThomasBoudier,
Thanks for explaining the format, what is the value information ? false or true ?
I guess in Icy the equivalent to these 3D Roi would be the 3DROIArea which is basically a 3D boolean mask.
Best,
– Stephane
Hi @Stephane,
The value information is only the id of the object, this field is here in case we want to store more information. For me a 3DRoi is a list of voxels pertaining to the ROI, not an image mask. Internally for computing purpose I convert it to an image mask.
So what is a 3DROIAREA, if I have a small object in the image, do I need to represent the whole 3D image and put TRUE only for the voxel of the 3D object ?
Maybe we need to open another topic (maybe with people interested with representation of 3D Roi, like @Christian_Tischer).
Best,
Thomas
Personally, I try use label mask images for everything as I think this is the most standardised format.
That’s an important question, as the data get unnecessary large in the case of sparse annotations. I think that @maarzt used some other way to store label images (i.e. masks) in the case of sparse annotations, e.g. in #labkit, right?
My argument is that if you use standard lossless compression algorithms (e.g. LZW for TIFF) on spares label images they become very small, at least on disk. However, if you “naively” load them into RAM they will uncompress to a potentially very large size. If you also want to keep it small in RAM then data structures like the ones used in LabKit may be indeed what you need.
Dear all,
Thank you Mathieu Fallet @mfallet for starting this thread.
I see two points in this discussion:
Icy interoperability
I think it would be great to extend the capacity of Icy to import and export different kind of ROIs. Interoperability between tools and softwares is key in bioimage analysis. @mfallet: would you have some example images and ROIs to share with the Icy team? We could see what can be implemented in Icy.
Also, is your question regarding scatterplots related to a specific need? Does the answer from @Stephane helps you?
ROIs versus label maps
In Icy, we use ROIs by default rather than label maps. I see from your messages that there is different practices. Maybe it would be worth opening a second thread on this?
Best regards,
Marion
Hi @MarionLouveaux ,
Yes you are right there are two important points :
We need to go to better interoperability between tools, and it seems that as for now a label image is the common way to go from tool to another to process and analyse labelled data. This thread may be of interest for all imaging community at large, and can be linked to more common discussion around New file format such as NGFF.
Another point is the internal representation of such ROI (especially in 3D) and it may differ from one library to another. This thread may interest developers as it may be useful to know the different practices.
Best,
Thomas
Well for me label images is all but standard, you have several way of interpreting them, it can be byte, short, int data internally without speaking about how defining 3D data but sure it’s still way better than proprietary ROI formats I would gladly choose a standardized ROI format it that could exist as it’s definitely more suited to represent annotations, objects… In Icy at least i believe that works quite well.
@ThomasBoudier
ROI have bounds information into them so for a 3D Area ROI, we have a 3D rectangle bounds and a 3D boolean mask defining the area. Also binary data of the mask is always ZIP encoded so for sparse data it still remains small on disk.
Best,
– Stephane
Probably I am naive, but for me the following workflow seems quite straightforward:
The disadvantage of only doing this however is that it can be extremly costly to, e.g. find object number 50 in a 10 TB image, because one has to do a connected component labelling of the whole thing. So one may need extra metadata, such as at least one anchor point (and even better a bounding box) for each object.
But I think @MarionLouveaux suggested that this was not the initial discussion of this thread. I am sorry if I was making it go off track! I’d be happy to continue this discussion somewhere else though if is there is interest.
The way you described it (a label image), there’s no need for connected-component analysis, but “just” for lookup of that pixel value. The “object” in the label image can even be several disconnected parts, as long as they all have the same label.
Yes, anchor points work, under the precondition that all objects are continous. 
Also, there are ROI implementations such as imglib2-roi that allow for overlapping labels (i.e. a given pixel can be part of two or more objects). In this case a simple label image is not enough, but you need a mapping between pixel values and sets of labels, which complicates the storage question a bit.
But I agree, in general the way you use label images is quite common.
Yes, of course, you are right! It was wrong what I said. Still “finding” all those pixels of the same value would in principle require iterating through the whole image, which is still quite expensive. Thus, some pointers as to where the pixels that belong to a given object are to be found can speed things up significantly.
Hi all involved in this dicussion,
I must admit I spent some time (years) thinking of the best way to represent ROI (mostly 3D), and we ended up with, internally, an object being a list of 3D voxel coordinates, and externally we use any type of labelled image (8,16 or 32 bits).
One point is also that usually a labelled image does not contain one ROI object but many.
This is why we have an additional layer of representation, an ObjectsPopulation, that is basically a list of 3D Roi, and quite fast algorithm extract this population from any labelled image.
Finally internally list of coordinates is usually quite efficient to process many objects, but sometimes you need an image (to compute co-localisation for instance), in this case we use a labelled image with only one object but restricted to the bounding box (similar to ICY); that means that this internal labelled image have information about its offset, so the ROI has correct coordinates
Best,
Thomas
Thanks to all for the discussion, I was under earth with covid. I agree we need better interoparibility between ROI format in particular in 3D and coordinates list are great to use. So maybe Icy and python,…, need to be compatible with the 3DROI from Thomas. Best Mathieu
For those interested in ImgLib2’s shape-based ROIs: they are described here:
Some features include both open and closed boundaries (as well as unspecified/unknown boundary type), unary and binary operations on ROIs (union, intersection, difference, etc.), treatment of ROIs as Java Predicates, and iteration of contained points in integer space. There are also converters for ImageJ1↔ImgLib2 and OMERO↔ImgLib2 (which when used together can convert ImageJ1↔OMERO).
There was talk for a while of implementing a persistence model (i.e. file format) for these ROI types, for use with e.g. #labkit, but ultimately I think the decision was made to store everything as labelings only? I’m not sure. @maarzt @tomburke-rse @tpietzsch Do you know?
