Strange behaviour when opening an MR image series lacking Slice location tag

[GoogleCodeExporter]

What steps will reproduce the problem?
1. In my case: Opening a 176-slice MR image series lacking the slice location 
tag (0020,1041).
2. When loading the data, it takes an unusually long time until I am able to 
start scrolling the images (~6 seconds).
3. I further notice three unexpected effects:
 - When scrolling, the images may seem to be displayed in a somewhat random order.
 - The position value in the upper left corner doesn't change when scrolling to new images.
 - The image counter is kind of wierd (shows 15490/30976) images, although the image series only has 176 images.

What is the expected output? What do you see instead?
I expect to be able to scroll through the images in the expected order, with 
the position and image counter displaying the expected values.

What version of the product are you using? On what operating system?
Dicompyler version 0.4.1-1 on WinXP SP3 32bit.

Please provide any additional information below.
Although I can't be sure of course what causes this, I do suspect that it is 
related to the fact that the image series in question lacks the slice location 
tag. However, it is not recommended to rely on this value when making DICOM 
software: one should instead use the Image position (patient) tag (0020,0032), 
as far as I'm aware anyway.

Original issue reported on code.google.com by chris.le...@gmail.com on 14 Mar 2012 at 9:55

Attachments:

• mr-expected.png
• mr-unexpected.png

[GoogleCodeExporter]

Since r57d9155cc415, dicompyler does not use Slice Location tag at all, but 
rather uses Image Position Patient. I have not personally seen this issue since 
then with any datasets I have access to.

I also have a CT studyset that I manually removed the slice location and it 
works fine. Do you think you can send an anonymized copy of the studyset to me 
for further testing?

Original comment by bastula on 14 Mar 2012 at 4:27