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

[Matt McCormick]

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 <fredrik.hellman at gmail.com> 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