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

Lowekamp, Bradley (NIH/NLM/LHC) [C] blowekamp at mail.nih.gov
Mon Sep 11 13:58:41 EDT 2017


I agree that filter has a nice option set for how to reduce the dimension of direction cosine matrix and update the physical coordinates. However, I would not try to re-implement or copy all those options and their implementations. If a new version of the filter was to be created, I’d recommend just reusing this recommended ExtractImageFilter in a mini-pipeline style composite filter.

Brad

On 9/11/17, 11:25 AM, "Matt McCormick" <matt.mccormick at kitware.com> wrote:

    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
    

_____________________________________
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


More information about the Community mailing list