[Insight-developers] Copying the state of the TimeVaryingVelocityFieldTransform

[Nicholas Tustison]

Sorry, Kent, but I completely misread your email.  I was referring to IO,
not copying.  I apologize.  In the case of copying, then, yes, the velocity
field transform would be something that you'd want to keep.


On Nov 15, 2011, at 12:53 PM, Williams, Norman K wrote:

> So what you're saying is that at the point where you want to copy a
> transform of that type, what you really care about is the data actually
> contained in the deformation field?  This feels like shaky ground to me,
> for a number of reasons, When is a transform's internal state not relevant
> to a copy of that transform? Should state variables that are only used
> when computing the transforms be explicitly labeled as such.
> 
> --
> Kent Williams norman-k-williams at uiowa.edu
> 
> 
> 
> 
> 
> 
> On 11/15/11 9:24 AM, "Nicholas Tustison" <ntustison at gmail.com> wrote:
> 
>> Hi Kent,
>> 
>> Thanks for tackling this.  I would opt for not saving the velocity field.
>> I suspect that when somebody gets to the stage of writing out the
>> transforms for storage, they're more concerned with the transformation
>> itself and not so much with how they arrived at the transformation
>> and the velocity field would fall under the latter category.
>> 
>> Nick
>> 
>> 
>> On Nov 15, 2011, at 10:16 AM, Williams, Norman K wrote:
>> 
>>> I've been working on a patch to allow Transforms to be copied.  This
>>> addresses a gap in the API for transforms: If you read a transform file,
>>> you only have read-only access to the transforms.  You can manually copy
>>> parameters from the const Transform to a newly instantiated transform of
>>> the same type, but this raises two problems:
>>> 
>>> 1. Transform state does not exist solely in the Parameters &
>>> FixedParameters, for several types of Transform.  If you need to make a
>>> copy you need to know how the internal state has been augmented with
>>> 'out
>>> of band' parameters.
>>> 
>>> 2. To copy a CompositeTransform, it would need to copy all its
>>> constituent
>>> transforms.
>>> 
>>> Adding a Clone method gives us a way to copy transforms in a single
>>> method, and the transforms themselves are responsible for overriding
>>> Clone
>>> to make sure the entire state is transformed.
>>> 
>>> The TimeVaryingVelocityFieldTransform is the one case where I am not
>>> sure
>>> about how to copy the internal state. It is a subclass of
>>> DisplacementField, but it has an additional Image-like member, the
>>> TimeVaryingVelocityField. Plus it also has an interpolator member. Do
>>> these all need to be copied?
>>> --
>>> Kent Williams norman-k-williams at uiowa.edu
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ________________________________
>>> Notice: This UI Health Care e-mail (including attachments) is covered
>>> by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
>>> confidential and may be legally privileged.  If you are not the intended
>>> recipient, you are hereby notified that any retention, dissemination,
>>> distribution, or copying of this communication is strictly prohibited.
>>> Please reply to the sender that you have received the message in error,
>>> then delete it.  Thank you.
>>> ________________________________
>> 
> 
> 
> 
> ________________________________
> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
> ________________________________