brian avants

2010-11-20 20:35:13 UTC

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)

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)

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

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

--

ß®∫∆π

ß®∫∆π