[Insight-developers] ShrinkFilter - Bugs from double precision

[Luis Ibanez]

Hi Brad,

I thought that in order to reduce computation time we were planning
to stay away from the methods:

  outputPtr->TransformIndexToPhysicalPoint( outputIndex, tempPoint );
  inputPtr->TransformPhysicalPointToIndex( tempPoint, inputIndex );

e.g. lines 253-254...

Probably I'm missing something again...


    Luis

--------------------------
Bradley Lowekamp wrote:
> The committed changes seem to achieve all the goals and desired behavior 
> everyone has been wanting for this class.
> 
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/BasicFilters/itkShrinkImageFilter.txx?root=Insight&r1=1.58&r2=1.60 
> <http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/BasicFilters/itkShrinkImageFilter.txx?root=Insight&r1=1.58&r2=1.60>
> 
> Any additional feedback or review of these changes would be appreciated 
> while I still have things fresh in my mind.
> 
> Thanks,
> Brad
> 
> 
> On Apr 9, 2009, at 10:30 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:
> 
>> Thank you! That explains it!
>>
>> I am still going to convert what can to index integer arithmetic and 
>> the remainder I will use your recommendation.
>>
>> Thanks,
>> Brad
>>
>> On Apr 9, 2009, at 10:14 AM, Tom Vercauteren wrote:
>>
>>> Hi Bradley,
>>>
>>> This is most certainly related to TransformPhysicalPointToIndex being 
>>> wrong:
>>> http://www.itk.org/Bug/view.php?id=6558
>>>
>>> Instead of rounding to the nearest integer,
>>> TransformPhysicalPointToIndex simply casts the coordinates so if your
>>> continuous index is
>>>  2.9999999999999999
>>> the corresponding index will be
>>>  2
>>> and not
>>>  3
>>>
>>> I usually stay away from TransformPhysicalPointToIndex and use
>>> TransformPhysicalPointToContinuousIndex followed by a loop of
>>> vnl_math_round.
>>>
>>> Tom
>>>
>>> On Thu, Apr 9, 2009 at 16:01, Bradley Lowekamp 
>>> <blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>> wrote:
>>>
>>>> To look into why my changes caused problem, I compared the computed 
>>>> index
>>>
>>>> between the ImageBase::Transform and the my supposed optimized algebraic
>>>
>>>> equivalent based on integer index operation.
>>>