<div dir="ltr"><div><div>Hi Aivar,<br><br></div><div>Sorry for ignoring this mail for so long...<br></div><div><br>> Another useful concept would be whether a dimension is DISCRETE<br><br></div>I agree; we should put this in to AxisType. We can do it on the pending img-metadata branch [1].<br>
<br>> What if an algorithm could somehow declare via annotation what sorts<br>> of dimensions it was interested in?<br><br></div>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.<br>
<div><div><br></div><div>I think both of your examples could be handled in this way, potentially.<br><br>> There's a lot of hand-waving here at present, particularly how this<br>> dimensional interest would be specified.<br>
<br></div><div>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.<br>
</div><div><br>> ([*] Another alternative would be my creating a custom<br>> FittedLifetimeType or some kind of generic TupleType)<br><br></div><div>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.<br>
<br>Regards,<br>Curtis<br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 10, 2013 at 3:26 PM, Aivar Grislis <span dir="ltr"><<a href="mailto:grislis@wisc.edu" target="_blank">grislis@wisc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.)<br>
<br>
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).<br>
<br>
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. [*]<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Hope this makes sense! There's a lot of hand-waving here at present, particularly how this dimensional interest would be specified.<br>
<br>
Thanks for reading,<br>
<br>
Aivar Grislis<br>
<br>
([*] Another alternative would be my creating a custom FittedLifetimeType or some kind of generic TupleType)<br>
<br>
<br>
______________________________<u></u>_________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net" target="_blank">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/<u></u>listinfo/imagej-devel</a><br>
</blockquote></div><br></div>