[ImageJ-devel] (ImgLib2) operations on two or more images with differing calibrations

[Tobias Pietzsch]

Hi Lee,

In analogy to integer transforms & views we should have AffineTransform, 
which maps (coordinate) vectors to vectors.

Then we would have a view class that implements RealRandomAccessible. 
This view class is what you referred to as CoordinateAffineTransform. 
It would take another RealRandomAccessible and an AffineTransform, as 
you described.

The AffineTransform in turn would tie into a transform hierarchy: 
Affine is probably the most general transform we would support.  So 
there will be an interface Affine which extends RealTransform. 
Interface Rigid would derive from Affine and so on.  This interface 
hierarchy specifies the transform hierarchy, e.g., a Rigid is also an 
Affine.  Then on the implementation side we have
public class AffineTransform implements Affine, Concatenable< Affine >, 
PreConcatenable< Affine > {...}.

Lets assume, we implement a restricted transform like scaling within the 
transform hierarchy.  Then the Scale (?) interface would derive from 
Affine and a ScaleTransform can be treated as an Affine.  This nicely 
separates the transforms from the implementation of the views, which 
will require implementing a RealRandomAccess that applies a transform to 
its position, etc. We can first do a general view implementation like 
your CoordinateAffineTransform.  You can naturally pass a Scale as the 
view transform.  This will be treated as a full Affine for the time 
being, doing a bit more work than necessary.  Later it is easy to write 
special cases for special transforms.  (For example, for the integer 
views there is a TranslationRandomAccess which is more efficient than 
the general MixedRandomAccess.)

Tobias

On 11/28/2011 07:16 PM, Lee Kamentsky wrote:
> All so cool - my preference would be to have a CoordinateAffineTransform
> class that implemented RealRandomAccessible. It would take another
> RealRandomAccessible as input as well as the affine transform matrix.
> That's very general and it separates interpolation from transformation
> so that you can choose the interpolation method you want to use (e.g.
> InterpolatedRandomAccessible) and you can use the
> CoordinateAffineTransform class for other sorts of
> RealRandomAccessibles. For scaling, it's just a question of populating
> the diagonal of the matrix appropriately, right?
>
> There are a lot of times when I'd like to treat images as functions that
> I could sample in a real space. For instance, in CellProfiler, we have a
> technique that uses spline interpolation to estimate variances in
> illumination. I'd like to divide my raw image by the spline
> interpolation and operate downstream on the result. I'm guessing that
> things like SIFT could be implemented very elegantly using
> RealRandomAccessibles whose output was a Gaussian transformation of a
> RandomAccessible input.
>
> OK, this is a joke, but I can see a slippery slope here to imglib3 where
> RandomAccessible is an artifact of images being stored using pixels and
> everything is done in a real space.
>
> --Lee
>
> On 11/28/2011 12:49 PM, Tobias Pietzsch wrote:
>> Hi ImgLib2 people,
>>
>> A while ago, Johannes asked about whether I had any thoughts on how
>> this (see subject) should be done. I finally had the time to look at
>> it now and found, that the ideas to do it are mostly in place (in my
>> opinion, at least) though implementation is not.
>>
>> I wrote a few thoughts on the wiki
>> http://fiji.sc/wiki/index.php/ImgLib2_Discussion#RealViews
>> What do you think?
>>
>> best regards,
>> Tobias
>>
>> _______________________________________________
>> ImageJ-devel mailing list
>> ImageJ-devel at imagejdev.org
>> http://imagejdev.org/mailman/listinfo/imagej-devel
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel