Re: [ITK-users] Can I alter the way SliceBySliceImageFilter defines the origin of the internal slices?

Yes, there are many ways handle the direction dimension collapse, and
it should be handled with care. If possible, we should follow the
behavior in ExtractImageFilter:

  https://itk.org/Doxygen/html/classitk_1_1ExtractImageFilter.html

which has multiple options.

Thanks,
Matt

On Mon, Sep 11, 2017 at 5:39 AM, hellman <[email protected]> wrote:
> I have been thinking a bit about this and realized this is slightly more
> complex problem than I first thought.
>
> Yes, as far as I can see, your suggested solution would (in my case) make
> the physical extents of the internal image and the image input projected to
> the XY 2D plane the same.
>
> But the current implementation ((even) with this bugfix) has two problems:
>
> 1. The projection of the original 3D origin onto the XY plane does not
> coincide with the new internal origin (there is nothing that says it should
> be, but to me it seems natural).
> 2. If the Direction matrix if the input would not be identity, the physical
> interpretation is unclear.
>
> It would be nice to have a procedure to compute the internal image meta-data
> that has some interpretation also when the Direction matrix is not identity.
> There are some conceptual problems the whole procedure of going to a
> 3D-origin to a 2D-origin:
>
> The input image 3D origin is defined in the physical frame of reference
> (FoR), while the image data is indexed in a different FoR that can be
> arbitrarily rotated with respect to the physical one, through the direction
> matrix.
>
> The SliceBySliceImageFilter slices in the index FoR and not in the physical
> FoR. This means that any plane (or line for 2D input, or hyperplane for
> higher dimensions) in the physical FoR can be the slicing plane. This in
> turn means it makes no sense to favor certain physical dimensions as is done
> in the current code. For example, just because we slice _index dimension 3_,
> does not mean we should (as is done today) compute the origin coordinates of
> the first pixel in physical coordinates and keep all physical coordinates
> except the one corresponding to _physical dimension 3_ in the new origin. I
> fail to see what is the physical interpretation of this.
>
> One solution that has a clear physical interpretation is the following.
> Consider the plane P orthogonal to the slicing dimension (spanned by the all
> columns of the input Direction matrix except the sliced dimension)
> intersecting the physical origin. The Direction matrix for the internal
> image would be Identity. This means we choose the _index FoR_ as slice FoR
> for expressing points in plane P in the slice. When considering a slice, the
> Origin of this slice would be projected onto this plane P and it would be
> expressed in the coordinates of the slice FoR. The Region from the input can
> simply be copied to the internal image (except for the sliced dimension),
> since it is just a matter of collapsing the sliced dimension.
>
>
>
> --
> Sent from: http://itk-users.7.n7.nabble.com/
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
_____________________________________
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.php

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://public.kitware.com/mailman/listinfo/insight-users