Thanks for reporting this.

Can you review these suggestions and see if you can provide more debugging information (e.g. ability to reproduce the data without sharing PHI)

http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/FAQ/DICOM

Also, can you add information to the report saying exactly how you load the individual bones? It's not clear from the report how you load only part of the axial series. Do you do this through some external software?

Hello Pieper,

Thanks for the response!

The CT temporal bones are straight from the CD from the CT scanner. NO post-processing or cropping on my part. The DICOM images were straight from the CD. Typically, they will do the entire head, and then high-resolution 0.625mm cuts through the right and left temporal bones. These are shown as separate series on the CD.

I have anonymized the DICOM stacks for you to see in the following link. There is the whole head as well as the RIGHT temporal bone -- both are on the same patient from the same scan CD.

The volume rendering on the right temporal bone shows a LEFT ear (even though the images are for the right). The whole head volume rendering seems to work well, but the coronal and saggital planes do not show up.

https://onedrive.live.com/redir?resid=997D1677213982DB!3857&authkey=!AIavkW0R_icTyOc&ithint=file%2czip

Thanks!

Hi -

Thanks for providing the data - the issue makes sense now. This exposed a logic error and also a user interface issue.

Let me start by describing the situation I see in the data:

• it appears that the RT Temporal lobe series was generated by some process either on the scanner or a workstation to create a derived series.

• one instance in the series has a different orientation and is a coronal map of where the new slices are. It arguably should be labeled as a secondary capture, but let's say it's valid.

Slicer correctly warns that there are geometry issues with the data. However the issue with slicer's logic was that the option was not exposed to load only the files with matching orientations. This is fixed as of r23697, and now it is possible to select the correct load option.

The GUI issue is multifold. First the correct volume is buried at the bottom of the list and not selected by default even though it is the best interpretation of the data. Perhaps the logic should be: confidence of a loadable is the one that has no warnings but includes the largest number of files.

The second GUI issue is that the warning only shows when you are in Advanced mode, so users may not see it. The solution to this is probably to add a popup when the non-Advanced mode causes a volume to load that includes a warning.

A third GUI issue is smaller, but still important and has been addressed in the ScalarVolumePlugin, which is that only the last warning would be displayed. As of r23697 this has been changed so each warning is concatenated to the end of the warning string. This could lead to a long string, but that's probably better than missing data.

I believe the remaining issues will require some thought so I will keep the bug open and re-assign it to Alireza to review and comment on.

For the record, the workaround is to remove the following file from the dicom data tree:

DICOM - Anonymous/Temporal Bone/DICOM/I00

The contents of this file are shown in the attached image "extra_instance.png" and it is clearly not usable as part of a series.

Thank you Pieper -- removing the file allowed the volume to work perfectly.

I will make sure I check for this from now on.

Please re-open if it is not fixed or close if you think this is resolved.

Thanks