[Insight-developers] Lots of new warnings: Adding an alternative GetInverse() method to the transform hierarchy.

[Luis Ibanez]

Hi Doug,

The reason for returning TransformBase is to avoid dependencies
with the Transform parameters, that will result in this GetInverse()
method to have a signature that differs only on the return value.

The use of this method in Slicer may be restricted to a specific
combination, but ITK is used by a much larger community for which
Slicer's restrictions may not apply.

Could you elaborate on the details of Astronomical transformations
for which the GetInverse() method should be virtual ?

This may help to find a better choice among the current options
of API for GetInverse().


    Thanks


        Luis



---------------------
Douglas Alan wrote:
> Luis Ibanez <luis.ibanez at kitware.com> wrote:
> 
> 
>>Giving the limitations of swig, it seems that the signature
>>
>>       virtual TransformBase::Pointer  GetInverse() const
>>
>>is a better option to try.
>>
>>
>>Doug: will this signature work for the coordinates conversions
>>       that you are looking for ?
> 
> 
> Yes, I think that this will be okay.  I'm a bit confused by GetInverse()
> returning a TransformBase object, however, rather than a Tranform<T1,
> N1, N2> object.  Is the reason for returning a TransformBase object so
> as to support inverses that are have a different scalar type, or a
> different number of input and/or output dimensions?
> 
> If in Slicer, T1, N2, and N2, are always the same, then I suppose that
> Slicer can safely downcast the TransformBase.  (It's safe to downcast
> ITK's smart pointers, right?)  If this doesn't hold true in Slicer,
> however, then it seems to me we just end up with more or less the same
> issue, albeit in a slightly different guise.
> 
> |>oug
>