I have a couple more ideas/questions/whatnots pertaining to ROIs, and I’d greatly appreciate your input on them.
- Is there a difference between something being
Positionable and something undergoing a translation?
Positionable only applied to moving single points/accessors within a given space; whereas, translation would be shifting the space itself (like a region or an interval). For example, if I wanted to move one vertex of a
Polygon then that vertex is
Positionable but if I wanted to move the entire
Polygon then that’s a translation. Is this distinction correct?
- Would it make sense to create methods like
Regions.rotate( … )?
This method would function similarly to
Regions.positionable( … ). In other words, it would check if the given
RealRandomAccessibleRealInterval is rotate-able and if so use its rotate method, otherwise use
RealViews to do the transformation. Something similar could be done for shear, scale, etc. Provided there was a need for them.
It seems as though there’s two possible ways to do this:
- Use binary operators to combine multiple regions (i.e. CompositeRegionOfInterest and @haesleinhuepf’s binary operators for ROIs)
- Use a list of closed curves and the even/odd winding rule (i.e. GeneralPathRegionOfInterest)
I feel like option two is useful when the user knows their desired shape. For example, creating the green region in the image below. Creating this shape is easy to do using option two, but is more cumbersome to create with option one because you’d have to create multiple ROIs and combine them a few times.
On the other hand, option one is useful if someone has two regions already defined, and would now like to define a third region which is the intersection of the two.
I can't decide which one of these options is better, so please let me know your thoughts on these two options.
- Should there be a way of retrieving the original real space ROI from the rasterized version?
So if I create a
RasterizedPolygon, should it store a reference to the
Polygon it was created from?
RandomAccessibleOnRealRandomAccessible does store a reference to the target
RealRandomAccessible but there is no way to access it.
You could use
Views.interpolate( … ) to try and reconstruct the original polygon, but it just seems like it would be easier to have the rasterized ROI keep track. Though if you transform the rasterized ROI, then you probably should use
View.interpolate( … ) to retrieve the equivalent real space ROI. Thoughts?
Both the rasterize and combine-able points (specifically option 1), kind of lend themselves to an additional requirement:
Mechanism for persisting ROIs.
So if you combine, rasterize, etc. a ROI you should be able to retrieve the original ROI.
@tpietzsch, @dietzc, @axtimwalde, @haesleinhuepf please let me know your thoughts on the above. Also please feel free to let me know if you have any additional thoughts/comments/questions on ROIs, all input is welcome.
And thanks again for all the feedback everyone! It has all been extremely helpful!