[ImageJ-devel] ImgLib2 dimensionality

Tue Jun 18 06:32:15 CDT 2013

Hi Aivar,

Sorry for ignoring this mail for so long...

> Another useful concept would be whether a dimension is DISCRETE

I agree; we should put this in to AxisType. We can do it on the pending
img-metadata branch [1].

> What if an algorithm could somehow declare via annotation what sorts
> of dimensions it was interested in?

I think the plan is to build a layer on top of ImgLib2 (a CalibratedViews
static utility class, probably) that can do things like detecting when an
Img has attached Axis metadata with a discrete dimension, and create
sub-Imgs at each discrete sample. Then you can execute whatever
dimension-agnostic algorithm you want on those sub-Imgs without clobbering
the discrete dimension(s), as you say.

I think both of your examples could be handled in this way, potentially.

> There's a lot of hand-waving here at present, particularly how this
> dimensional interest would be specified.

Indeed, I am also not certain exactly what my proposed layer would look
like. I agree that it would be ideal to have some convenient way of
specifying which (types of) dimensions are of interest when subdividing
images. There may also be an argument to passing the entire Img rather than
a sub-Img, if the "non-interesting" dimensions are rather "interesting for
decision-making but not to be operated upon directly." I don't know.

> ([*] Another alternative would be my creating a custom
> FittedLifetimeType or some kind of generic TupleType)

Hopefully we won't have to go that route... custom types are powerful but
also incompatible with the wealth of code already in existence that uses
regular types.

Regards,
Curtis

On Thu, Jan 10, 2013 at 3:26 PM, Aivar Grislis <grislis at wisc.edu> wrote:

> I was looking at the dimensional code in net.imglib2.meta.Axes. This is an
> enum of known, named AxisTypes such as X, Y, Z..., has the capacity for
> CustomAxisTypes, and some sort of characterization of these dimensions with
> 'isXY()' and 'isSpatial()'.  (Perhaps we could replace these latter with
> some kind of EnumSet of DimensionTypes, such as XY, SPATIAL, etc. for the
> discussion that follows.)
>
> It might be useful to have a concept of a COINCIDENTAL type.  This sort of
> dimension represents different aspects of the same pixel/voxel/doxel.  It's
> as if you look at it with red glasses, blue glasses, etc.  Effectively this
> is the same as non-spatial/-temporal since all of the default AxisTypes
> besides XYZT would be coincidental.  But with this you can specify if a new
> CustomAxisType should be coincidental or not.  For example, if you wrote a
> plugin that works on an image in 5D that is a series of 4D (XYZT) images,
> the dimension that represents the series of images is not coincidental (and
> not spatial or temporal either).
>
> Another useful concept would be whether a dimension is DISCRETE (or
> NON_INTERPOLABLE?).   This sort of image would be analogous to a table of
> height/weight/shoe size per individual (pixel).  This works only because it
> happens you can express all three measurements as floating point.  Anyway,
> the point is these measurements are totally independent, the order is
> arbitrary, and it never would make any sense to combine them somehow or
> interpolate between them.  I've been working on a FLIM fitting plugin and
> using such images as my output, where the measurements are a set of fitted
> lifetime parameters, for example A1, T1, A2, T2, Z, all doubles.  It's the
> equivalent of five separate images in one and could just be refactored as
> such. [*]
>
> My motivating concern was that if were to introduce such a DISCRETE
> DimensionType most existing plugins or algorithms will not do anything
> useful (other than simple things like copying, etc.).  In fact they will
> most likely clobber my discrete dimension.
>
> What if an algorithm could somehow declare via annotation what sorts of
> dimensions it was interested in?  Without such an annotation the default
> would be to get all of the non-discrete dimensions, and the caller splits
> the image into sub images across discrete dimensions and processes them
> successively.  Then existing algorithms could do useful work on my discrete
> image.  Other algorithms that understand the meaning of this discrete
> dimension information could declare an interest in it and get the whole
> thing.
>
> This could be a very useful mechanism in other instances.  In general lets
> say an algorithm could specify dimension types or specific dimensions of
> interest and the caller splits the image into sub images across the
> remaining dimensions.  Then the algorithm gets a cursor that iterates only
> on the dimensions of interest.  They could set the cursor position within
> these dimensions or just iterate through the whole thing.
>
> Another use case might be to split up arbitrary images into XY slices for
> 2D-processing algorithms. On the input side, my FLIM fitting algorithm
> could declare an interest in the LIFETIME AxisType only and get called
> pixel by pixel with a lifetime dimension cursor to process a whole image
> that has unknown dimensions.
>
> For another example, the early ImgLib1 sample Floyd-Steinberg dithering
> algorithm could process only non-COINCIDENTAL dimensions. This would avoid
> distributing errors from the red channel to the blue channel, for instance;
> they would be dithered one by one.
>
> Hope this makes sense!  There's a lot of hand-waving here at present,
> particularly how this dimensional interest would be specified.
>
> Thanks for reading,
>
> Aivar Grislis
>
> ([*] Another alternative would be my creating a custom FittedLifetimeType
> or some kind of generic TupleType)
>
>
> ______________________________**_________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/**listinfo/imagej-devel<http://imagej.net/mailman/listinfo/imagej-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130618/44efc823/attachment.html>