Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Back/forward Drift between image planes of a MRI series
41 views
Skip to first unread message
Christoph Conrad
Feb 10, 2012, 4:06:20 AM2/10/12
to
Hello,
we have a strange effect in a 56 image series of tomograms from a knee.
Maybe someone has an explanation.
All images have ascending "Slice Location" (20,1041) 0,2,4... All have
monotonously increasing or decreasing x/y/z for "Image Position"
(20,32). Image position points seem to be loacted on a straight line,
ichecked that for several points. "Image Orientation" (20,37) is
identical for all images, roughly sagittal, the plane is rotated 22
degrees around the z axis.
But: there is a drift every second image, so that when you scroll
forward and see the image sequence, image 2 is shifted right against
image 1, and image 3 shifted left against image 3, but right against
image 1, and so forth. If you reconstruct a volume from this images you
clearly see an aliasing.
We did not reconstruct the images according to DICOM standard "PS
3.1-2011" "C.7.6.2.1.1 Image Position And Image Orientation". We
segmented the bone section in the original images and then reconstructed
the 3D volume.
Regards,
Christoph
we have a strange effect in a 56 image series of tomograms from a knee.
Maybe someone has an explanation.
All images have ascending "Slice Location" (20,1041) 0,2,4... All have
monotonously increasing or decreasing x/y/z for "Image Position"
(20,32). Image position points seem to be loacted on a straight line,
ichecked that for several points. "Image Orientation" (20,37) is
identical for all images, roughly sagittal, the plane is rotated 22
degrees around the z axis.
But: there is a drift every second image, so that when you scroll
forward and see the image sequence, image 2 is shifted right against
image 1, and image 3 shifted left against image 3, but right against
image 1, and so forth. If you reconstruct a volume from this images you
clearly see an aliasing.
We did not reconstruct the images according to DICOM standard "PS
3.1-2011" "C.7.6.2.1.1 Image Position And Image Orientation". We
segmented the bone section in the original images and then reconstructed
the 3D volume.
Regards,
Christoph
Wim Corbijn
Feb 18, 2012, 4:22:41 AM2/18/12
to
On Feb 10, 2:06 pm, "Christoph Conrad" <spamcrunc...@digital-
Cristoph,
Your description is not clear for me.
What do you mean with shifted in this case (beside the typo in
numbers).
How do you scroll through the images and see images against each
other?
How can you reconstruct a 3D volume without taking position and
orientation into account.
Be aware that slice location is a parameter that has no hard
definition and every vendor uses it's own logic for this.
Meaning I wouldn't use it for any other purpose than some kind of
order.
The fact that the volume is rotated influences the distance between
pixels in the different images.
I expect that if you don't take this into account you might get
strange effects.
Regards,
Wim
Your description is not clear for me.
What do you mean with shifted in this case (beside the typo in
numbers).
How do you scroll through the images and see images against each
other?
How can you reconstruct a 3D volume without taking position and
orientation into account.
Be aware that slice location is a parameter that has no hard
definition and every vendor uses it's own logic for this.
Meaning I wouldn't use it for any other purpose than some kind of
order.
The fact that the volume is rotated influences the distance between
pixels in the different images.
I expect that if you don't take this into account you might get
strange effects.
Regards,
Wim
Christoph Conrad
Feb 22, 2012, 4:59:32 AM2/22/12
to
Hi Wim,
* Wim Corbijn <joj...@gmail.com> schrieb:
> Your description is not clear for me. What do you mean with shifted in
> this case (beside the typo in numbers).
When you see the images in ascending "Slice Location" then every second
image is shifted left against the position you would expect according to
the sequence of images seen as a "movie" of images.
> How do you scroll through the images and see images against each
> other?
You see the images separate, it is simply that you change between the
images fast forward (or fast backward).
> How can you reconstruct a 3D volume without taking position and
> orientation into account.
I know the correct formula, as i wrote, but how can there be a shift as
described when all images are parallel, equidistant, and all image
positions are on a straight line?
I reconstructed 3D volumes with several free programs and all showed the
effect seen in 2D also in 3D. So i conclude that there either is an
error in the data or all programs missinterpret/do not use some kind or
several parameters of the image.
> Be aware that slice location is a parameter that has no hard
> definition and every vendor uses it's own logic for this.
"slice lication" is defined as "the relative position of the image plane
expressed in mm. This information is relative to an unspecified
implementation specific reference point." So when all planes are
parallel (same "Image Orientation") you can compute the distance of two
planes by subtracting their "slice locations" and also order them, as
you did wrote.
Regards,
Christoph
* Wim Corbijn <joj...@gmail.com> schrieb:
> Your description is not clear for me. What do you mean with shifted in
> this case (beside the typo in numbers).
image is shifted left against the position you would expect according to
the sequence of images seen as a "movie" of images.
> How do you scroll through the images and see images against each
> other?
images fast forward (or fast backward).
> How can you reconstruct a 3D volume without taking position and
> orientation into account.
described when all images are parallel, equidistant, and all image
positions are on a straight line?
I reconstructed 3D volumes with several free programs and all showed the
effect seen in 2D also in 3D. So i conclude that there either is an
error in the data or all programs missinterpret/do not use some kind or
several parameters of the image.
> Be aware that slice location is a parameter that has no hard
> definition and every vendor uses it's own logic for this.
expressed in mm. This information is relative to an unspecified
implementation specific reference point." So when all planes are
parallel (same "Image Orientation") you can compute the distance of two
planes by subtracting their "slice locations" and also order them, as
you did wrote.
Regards,
Christoph
Wim Corbijn
Feb 23, 2012, 10:34:56 AM2/23/12
to
On Feb 22, 2:59 pm, "Christoph Conrad" <spamcrunc...@digital-
filestore.de> wrote:
> Hi Wim,
>
> * Wim Corbijn <jojo...@gmail.com> schrieb:
Hi Cristhoph,
You are correct if the slice location is indeed correctly calculated.
As a test I would check the distance by calculating the distance
between the Image positions of two of the successive images.
If your correct this should give you the 2 mm from slice location
difference.
By the way is the line through the image positions perpendicular to
the image plane?
Will expect this but might be good to check this.
Your volume might not be a cube.
Why are you not using the standard Space between slices and the slice
thickness.
These will give you the needed information directly, independent from
slice location.
Is slice thickness of any influence for your algorithm, what if there
is a real distance/gap between the slices?
Sorry only questions no real answer yet.
My feeling is that your assumption about slice location might be not
correct.
I never felt comfortable with the "unspecified specific reference
point".
Is to easy to make mistakes with such an open definition, we have had
quite some discussions about it.
Regards,
Wim
filestore.de> wrote:
> Hi Wim,
>
> * Wim Corbijn <jojo...@gmail.com> schrieb:
You are correct if the slice location is indeed correctly calculated.
As a test I would check the distance by calculating the distance
between the Image positions of two of the successive images.
If your correct this should give you the 2 mm from slice location
difference.
By the way is the line through the image positions perpendicular to
the image plane?
Will expect this but might be good to check this.
Your volume might not be a cube.
Why are you not using the standard Space between slices and the slice
thickness.
These will give you the needed information directly, independent from
slice location.
Is slice thickness of any influence for your algorithm, what if there
is a real distance/gap between the slices?
Sorry only questions no real answer yet.
My feeling is that your assumption about slice location might be not
correct.
I never felt comfortable with the "unspecified specific reference
point".
Is to easy to make mistakes with such an open definition, we have had
quite some discussions about it.
Regards,
Wim
Christoph Conrad
Feb 27, 2012, 3:24:46 AM2/27/12
to
Hi Wim,
[uploaded anonymized series, see at the end]
> As a test I would check the distance by calculating the distance
> between the Image positions of two of the successive images. If your
> correct this should give you the 2 mm from slice location difference.
Computing the image position between the first and last slice gives 110
mm, this is 55 slice distances * 2 mm. Looks ok.
> By the way is the line through the image positions perpendicular to
> the image plane? Will expect this but might be good to check this.
> Your volume might not be a cube.
Yes, thats correct and i thought of this, but image positions are on a
straight line (i checked that) and that should be sufficient (together
with "slices are parallel").
> Why are you not using the standard Space between slices and the slice
> thickness. These will give you the needed information directly,
> independent from slice location.
I agree, but all informations do "fit together" for parallel slices.
> Is slice thickness of any influence for your algorithm, what if there
> is a real distance/gap between the slices?
Slice thickness/spacing between slices both is 2 mm.
> Sorry only questions no real answer yet.
No - thank you for discussing this. And questions are the path to truth
;-)
> I never felt comfortable with the "unspecified specific reference
> point". Is to easy to make mistakes with such an open definition, we
> have had quite some discussions about it.
I feel that it is a complete definition, leaving no room for
interpretation. The implementation defines a (specific) reference point,
which actual position is of no importance to the user (unspecified).
Regards,
Christoph
If you want to have a look for yourself, see
https://rapidshare.com/files/3385702108/Anon.zip
[uploaded anonymized series, see at the end]
> As a test I would check the distance by calculating the distance
> between the Image positions of two of the successive images. If your
> correct this should give you the 2 mm from slice location difference.
mm, this is 55 slice distances * 2 mm. Looks ok.
> By the way is the line through the image positions perpendicular to
> the image plane? Will expect this but might be good to check this.
> Your volume might not be a cube.
straight line (i checked that) and that should be sufficient (together
with "slices are parallel").
> Why are you not using the standard Space between slices and the slice
> thickness. These will give you the needed information directly,
> independent from slice location.
> Is slice thickness of any influence for your algorithm, what if there
> is a real distance/gap between the slices?
> Sorry only questions no real answer yet.
;-)
> I never felt comfortable with the "unspecified specific reference
> point". Is to easy to make mistakes with such an open definition, we
> have had quite some discussions about it.
interpretation. The implementation defines a (specific) reference point,
which actual position is of no importance to the user (unspecified).
Regards,
Christoph
If you want to have a look for yourself, see
https://rapidshare.com/files/3385702108/Anon.zip
David Clunie
Feb 27, 2012, 9:58:27 AM2/27/12
to
Hi Cristoph
Is this an interleaved acquisition in which there may have been
patient motion between the two averaging periods ?
That's what your images suggest to me visually, anyway.
This is a well recognized phenomenon, and some folks have
attempted to apply registration techniques to deal with this;
see for example:
"http://144.206.159.178/ft/CONF/16428378/16428472.pdf"
From a DICOM perspective a patient coordinate system as defined
by a common frame of reference UID is only as good as the
amount of motion of the patient during the acquisitions within
that frame of reference.
David
PS. I don't know enough about Philips scanners or their pulse
sequences or their private attributes to be able to tell; that
said, there do not seem to be any variations in the header
attributes from frame to frame that would allow one to know
during which acquisition interval each frame was acquired,
assuming that they are interleaved, or that they are interleave
in the first place; perhaps Wim can answer that question.
PPS. I agree with Cristoph that SliceLocation should never be
used for geometry calculations - always use ImagePositionPatient.
Likewise, ignore SliceThickness and SpacingBetweenSlices, and
compute the interval along the normal to ImageOrientationPatient
Is this an interleaved acquisition in which there may have been
patient motion between the two averaging periods ?
That's what your images suggest to me visually, anyway.
This is a well recognized phenomenon, and some folks have
attempted to apply registration techniques to deal with this;
see for example:
"http://144.206.159.178/ft/CONF/16428378/16428472.pdf"
From a DICOM perspective a patient coordinate system as defined
by a common frame of reference UID is only as good as the
amount of motion of the patient during the acquisitions within
that frame of reference.
David
PS. I don't know enough about Philips scanners or their pulse
sequences or their private attributes to be able to tell; that
said, there do not seem to be any variations in the header
attributes from frame to frame that would allow one to know
during which acquisition interval each frame was acquired,
assuming that they are interleaved, or that they are interleave
in the first place; perhaps Wim can answer that question.
PPS. I agree with Cristoph that SliceLocation should never be
used for geometry calculations - always use ImagePositionPatient.
Likewise, ignore SliceThickness and SpacingBetweenSlices, and
compute the interval along the normal to ImageOrientationPatient
David Clunie
Feb 27, 2012, 10:04:29 AM2/27/12
to
Sorry, meant to say a"agree with Wim" ...
Christoph Conrad
Feb 28, 2012, 3:56:54 AM2/28/12
to
Hi David,
> Is this an interleaved acquisition in which there may have been
> patient motion between the two averaging periods ?
> That's what your images suggest to me visually, anyway.
This is a good explanation and together with the PDF paper outlines a
possible solution. Thank you very much!
> there do not seem to be any variations in the header attributes from
> frame to frame that would allow one to know during which acquisition
> interval each frame was acquired, assuming that they are interleaved,
Yes, it would be helpful to separate the interleaved images
automatically.
Regards,
Christoph
> Is this an interleaved acquisition in which there may have been
> patient motion between the two averaging periods ?
> That's what your images suggest to me visually, anyway.
possible solution. Thank you very much!
> there do not seem to be any variations in the header attributes from
> frame to frame that would allow one to know during which acquisition
> interval each frame was acquired, assuming that they are interleaved,
automatically.
Regards,
Christoph
Wim Corbijn
Mar 1, 2012, 3:58:04 AM3/1/12
to
On Feb 28, 1:56 pm, "Christoph Conrad" <spamcrunc...@digital-
Hi Christoph,
Tried to check the dataset you have send, but cannot see if it is
indeed scanned as two sets.
See the problem and application specialist indeed expects two sets
with small movement in between.
For this we would need to have the definition of the scans that are
normally stored as private objects.
If you have these than we can check.
Regards,
Wim
Tried to check the dataset you have send, but cannot see if it is
indeed scanned as two sets.
See the problem and application specialist indeed expects two sets
with small movement in between.
For this we would need to have the definition of the scans that are
normally stored as private objects.
If you have these than we can check.
Regards,
Wim
Christoph Conrad
Mar 1, 2012, 10:02:18 AM3/1/12
to
Hi Wim,
> Tried to check the dataset you have send, but cannot see if it is
> indeed scanned as two sets. See the problem and application specialist
> indeed expects two sets with small movement in between. For this we
> would need to have the definition of the scans that are normally
> stored as private objects. If you have these than we can check.
Thanks - would it be sufficient to send you the DICOMDIR via mail (done
so)? I am not able to anonymize that file.
Regards,
Christoph
> Tried to check the dataset you have send, but cannot see if it is
> indeed scanned as two sets. See the problem and application specialist
> indeed expects two sets with small movement in between. For this we
> would need to have the definition of the scans that are normally
> stored as private objects. If you have these than we can check.
so)? I am not able to anonymize that file.
Regards,
Christoph
0 new messages