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

Mon Sep 11 11:31:50 EDT 2017

Hello,

I few years ago I spent a bit of time with the SliceBySliceImageFilter to get the filter to “stream”. The way it was implemented was to expand the requested region of the output to the full size of the input’s in the non-slice-by-slice dimensions so that whole slices could be streamed through the filter. From your post, it may be the case that if the input image’s largest possible region starts with a non-zero index, then the computation of the origin per-slice is not proper. Can you please try to the filter with a zero-indexed input image?

I am not certain the previous prosed fix will work properly with streaming, and it may change the number of pixels in the regions…

However, for your case with an input image and an identity direction cosine matrix but with an non-zero largest possible index, it appears that the origin for the internal images is not correct. The non-zero index is a case that is not often checked by the ITK testing infrastructure, so I am not surprised it has a bug. Generally, it’s best to avoid such complex images with complex filters such as the SliceBySliceImageFilter. I have a proposed fix which may solve the problem for your case:
http://review.source.kitware.com/#/c/22601/

I need to add tests and verify this is proper. Perhaps, you can test it to see if it meets your needs and behaves as expected for you?

Also for reference here is the Slicer module I implemented which streams the SliceBySliceImageFilter. The streaming and proper geometry are critical for this application, so any changes made to this filter, I’ll need to ensure it still operates correctly.
https://github.com/blowekamp/Slicer-IASEM/blob/master/IASEMImportSeries/IASEMImportSeries.cxx

Brad

On 9/11/17, 5:40 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