# DICOM: calculated slice position is different from the DICOM header

629 views
Skip to first unread message

### Luca Pamparana

unread,
Oct 21, 2016, 11:19:17 AM10/21/16
to
I am implementing a method to spatially sort DICOM slices in a volume. The way I am doing it is to sort by the position along the slice normal. This is computed as:

slice_normal = [0, 0, 0]
dir_cosines = ds[0x0020, 0x0037] # Direction cosines
slice_normal[0] = dir_cosines[1] * dir_cosines[5] - dir_cosines[2] * dir_cosines[4]
slice_normal[1] = dir_cosines[2] * dir_cosines[3] - dir_cosines[0] * dir_cosines[5]
slice_normal[2] = dir_cosines[0] * dir_cosines[4] - dir_cosines[1] * dir_cosines[3]

image_pos = ds[0x0020, 0x0032] # IPP
distance_along_normal = 0
for i in range(len(slice_normal)):
distance_along_normal += slice_normal[i] * image_pos[i]

Now this value distance_along_normal should be equal to the slice position, except in my case it has the opposite sign. So the slice ordering seems to be reversed than what it should be. So, I must need to take something else into account to correctly compute the slice position.

Any ideas?

### c.w.c...@gmail.com

unread,
Oct 23, 2016, 10:09:14 AM10/23/16
to
Hi Luca,

I assume you mean Slice location as Slice position does not exist, Slice location has an open definition as it is the distance to a unspecified point, with this you could get differences. Even the one you describe I would say.

Secondly why do you calculate the slice position if you have the image position?

Regards,
Wim

### jdg...@innolitics.com

unread,
Jan 8, 2017, 2:11:53 PM1/8/17
to
Luca,

I stepped through your code, and I believe it is correct. Needless to say, we use the same approach:

1. Find Slice Direction Cosine by taking the cross product of the Row and Column cosines [1]
2. Find the component of the patient position along the slice direction cosine [2]

As Wim said, however, one should not expect for these to line up with the slice position, because the standard says:

> Slice Location (0020,1041) is defined as the relative position of the image plane expressed in mm. This information is relative to an unspecified implementation specific reference point. [3]

[1] http://dicom.innolitics.com/ciods/ct-image/image-plane/00200037
[2] http://dicom.innolitics.com/ciods/ct-image/image-plane/00200032
[3] http://dicom.innolitics.com/ciods/ct-image/image-plane/00201041

### Mathieu Malaterre

unread,
Jan 9, 2017, 2:49:13 AM1/9/17
to
On Sunday, January 8, 2017 at 8:11:53 PM UTC+1, jdg...@innolitics.com wrote:
> [1] http://dicom.innolitics.com/ciods/ct-image/image-plane/00200037

UI looks pretty cool ! You should prefer the chunked HTML though instead of the single page one.

### jdg...@innolitics.com

unread,
Jan 9, 2017, 3:48:07 PM1/9/17
to
Thanks Mathieu. We use the DICOM standard quite a bit with our work, but we found that it can be difficult to browse so we put together this tool for DICOM software developers.

Good point about using the chunked HTML pages--they would load much more quickly.

If you have any other ideas for improvements, please pass them along.

### Jörg Riesmeier

unread,
Jan 10, 2017, 5:28:42 AM1/10/17
to
> If you have any other ideas for improvements, please pass them along.

As I already wrote on StackOverflow: there seems to be a bug in your DICOM part 3 parser. E.g., in Patient Module the "Type of Patient ID" is nested in a sequence item. The same applies to nested macro, e.g. "Issuer of Patient ID Macro Attributes" within the "Other Patient IDs Sequence".

Also recursive structures as used quite intensively for the various SR IODs are not that easy to understand (and partly incorrect) in your tree-like representation.

Apart from that, it's a nice tool :)

Regards,
Jörg

PS: For implementation purposes, I recommend to use the official version of the DICOM standard. And by the way, only the PDF version is authoritative.

### Mathieu Malaterre

unread,
Jan 10, 2017, 6:07:17 AM1/10/17
to
On Tuesday, January 10, 2017 at 11:28:42 AM UTC+1, Jörg Riesmeier wrote:
> > If you have any other ideas for improvements, please pass them along.
>
> As I already wrote on StackOverflow:

With the reference: http://stackoverflow.com/a/41536265/136285

### jdg...@innolitics.com

unread,
Jan 10, 2017, 12:08:52 PM1/10/17
to
Jörg,

Thank you for the comments, these are very helpful.

I looked into the "Type of Patient ID" bug and you are absolutely correct---our Macro "expander" added attributes at incorrect locations.

We will need to think about how to better represent recursive structures. Would you mind if I contact you once we have some ideas on how to approach this?

Another issue we want to address is "shadowed" attributes---attributes that are included from multiple modules, some at higher precedence than others. For example, in the Enhanced CT CIOD:

http://dicom.innolitics.com/ciods/enhanced-ct-image/general-equipment/00080070

is "shadowed" by

http://dicom.innolitics.com/ciods/enhanced-ct-image/enhanced-general-equipment/00080070

Our current idea is to strikethrough the attributes with lower precedence, and perhaps include a link to the attribute that is shadowing it.

We want to make the tool as useful a resource for DICOM software developers as we can, but ultimately it is essential to verify against the pdf version of the DICOM standard. We are hoping to make it easy to cross check by including links to the official standard throughout the tool. Perhaps we should also add a comment in the foot note emphasizing how important this is.

Best,
David

### Jim Irrer

unread,
Jan 10, 2017, 12:36:30 PM1/10/17
to
Indeed, a VERY nice interface! Thank you for making it available.

Since you ask for improvements, I would suggest a search capability (unless
there is one and I missed it).

- Jim Irrer

### jdg...@innolitics.com

unread,
Jan 10, 2017, 1:14:02 PM1/10/17
to
Jim,

We have had several people ask for search. It is currently at the top of our list (after fixing bugs, like the one Jörg noticed) of features to add.

Thank you for your feedback.

David

### c.w.c...@gmail.com

unread,
Jan 16, 2017, 12:15:00 AM1/16/17
to
Hi David,

You might consider the usage of the chtml pages instead of the full PS3.3 html page. Might speed up when looking for the details.
Maybe it is my place but the DICOM page was slow.
Tool looks indeed very nice.

Wim

### Katie Somerville

unread,
Mar 10, 2022, 7:15:23 PMMar 10
to
nmgngnnmgfngbh6bthngg
Reply all
Reply to author
Forward
0 new messages