[Insight-users] multi-resolution pyramid - origin problem

[Luis Ibanez]

Hi Lars,

Thanks for pointing this out.

The origins are actually computed correctly,

Although it is understandable that you may be surprised by the
way the origin of the image changes at every resolution level.

Here is the rationale for recomputing the image origin:

We want to make sure that if the image contains an object,
the center of mass of that object doesn't change its physical
coordinates at every resolution level.

The sub-pixel refinement of the image origin must be done
at every resolution level in order to ensure this stability
property.  (It actually took a lot of hard work to get it to
behave this way)


The image will "look" shifted if you look at them with
a viewer that doesn't take into account the coordinates
of the image origin.

You may want to look at them with:

A) Paraview (www.paraview.org), and/or
B) Slicer (www.slicer.org)


   Regards,


          Luis


-------------------------------------------------------------------------------------
On Fri, Apr 16, 2010 at 2:59 AM, Lars Friedrich Lars <lars-friedrich at gmx.net
> wrote:

> Hello,
>
> when using itk::MultiResolutionPyramidImageFilter for shrinking a 2D image
> over 3 levels (schedule 4 4 / 2 2 / 1 1) I recognized that the resultant
> output origins of the images in level 0 (4 4) and level 1 (2 2) seem to be
> 'incorrect'.
>
> original image (=level 2):
> origin=+205,-205 dimension=410,410 spacing=1,1 direction=1 0 0 1
>
> --> pyramid output:
> level 0:
> ORIGIN=+206.5,-203.5 dimension=102,102 spacing=4,4 direction=1 0 0 1
> level 1:
> ORIGIN=+205.5,-204.5 dimension=205,205 spacing=2,2 direction=1 0 0 1
>
> To my mind the outputs at levels 0 and 1 seem to be incorrectly shifted by
> 0.5*originalspacing.
> --> desired output origins:
> level 0:
> ORIGIN=+206,-204
> level 1:
> ORIGIN=+205,-205
>
> When I compare the output images from level 0 and 1 to the original image,
> I can see the shift visually. Manually changing the output to the desired
> values 'fixes' the problem, and the overlay of the compared images shows a
> better visual agreement.
>
> This is the code fragment from itkMultiResolutionPyramidImageFilter.txx
> which is responsible for the shift:
> //Now compute the new shifted origin for the updated levels;
> const typename OutputImageType::PointType::VectorType outputOriginOffset
>         =(inputDirection*(outputSpacing-inputSpacing))*0.5;
>
>
> Is this a bug or a feature? Does the shift account for smoothing-effects of
> the internally used discrete gaussian smoothing filter or shrinking-effects
> of the shrink image filter?
>
> Thank you!
>
> regards,
>
> lars
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100419/c9be493d/attachment.htm>