[Insight-developers] vector transformation / reorientation

[brian avants]

hi everyone

it's time to start thinking about how we want to transform
vectors/tensors --- important for tensor registration, etc.  does
anyone have strong opinions about how this should be implemented in
itk-v4?   the important question is how to incorporate tensor/vector
reorientation for affine & deformable transformations.

some options:

1.  a filter that takes in an already resampled (by the resample image
filter)  vector/tensor image, a transformation and a reorientation
option (if necessary) and outputs the reoriented image.   the
disadvantage is that the user would need to apply this filter after
resampling and would have to know how and why this needs to be done.

2.  an implementation that "hides" the reorientation from the user.
that is, the reorientation is applied to the tensor/vector after the
resampling is performed but, perhaps, within the resample filter.  the
issue, here, is that we'd have to assume that a vector pixel
represents a geometric vector / tensor.   e.g. the CovariantVector or
SymmetricSecondRankTensor.   if someone uses the geometric vector type
incorrectly, e.g. to represent RGB, then they will get baffling
results.   one nice thing about this approach is we use only one loop
over the data for the resampling and reorientation.

generally, spatial jacobian maps are required for these operations to
be available.

Michael Stauffer pointed out that the transform base class currently
has unimplemented TransformVector and TransformCovariantVector
functions.   does anyone know what these were intended to implement,
specifically?  e.g. if the transformation is an affine transformation,
what would these functions do to the input vector?  for instance, the
functions may only resample the vector into the new space and not
reorient them.   alternatively, the vectors may be both transformed
and reoriented under rotation.  a third option is that they would be
transformed, reoriented and scaled under the full affine
transformation.  all of these use cases may come up.  and would the
behavior for TransformVector and TransformCovariantVector be the same?

my feeling is that vectors should be resampled by exploiting the same
functionality as one would for a scalar.  then reorientation should be
applied afterward via a separate operation either exposed to the user
(option 1 above) or applied implicitly (option 2).   if we choose
option 2, then the datatype would have to encode the type of
reorientation that would be expected.  i do not think current itk data
types are sufficiently specific to support this.

if there are no opinions about this, then we will probably lean
towards option 1 which will force people to think about what type of
reorientation they should use for their data.   on the other hand, for
some cases where data type is specific enough (e.g. DTI) we would
prefer option 2.

As always,

Brian


On Fri, Nov 19, 2010 at 3:59 PM, Michael Stauffer (Circular Logic)
<mstauffer at circular-logic.com> wrote:
> Hi Brian,
>
> The latest itkTransform class has new (pure virtual) transform methods,
> see below. What does it mean to transform a vector or covariantvector
> with a deformation field? for now, I'll just implement them and throw an
> exception so I can get the rest of the code up for starting review.
>
>  virtual OutputVectorType    TransformVector(const InputVectorType &)
> const = 0;
>  virtual OutputVnlVectorType TransformVector(const InputVnlVectorType
> &) const = 0;
>  virtual OutputCovariantVectorType TransformCovariantVector(const
> InputCovariantVectorType &) const = 0;
>  virtual void SetParameters(const ParametersType &) = 0;
>  virtual void SetParametersByValue(const ParametersType & p)
>  { this->SetParameters (p); }
>  virtual void SetFixedParameters(const ParametersType &) = 0;
>
> -M
>
>



-- 
ß®∫∆π