Problem in Volume Rendering

Support
1

Hello everyone,
In the Volume Rendering module, the image is very small location in the corner of the 3D tube. The information about this showed "irregular volume geometry detected. What is the reason about this and how to correct it?
Thanks,
Xie

40%20PM
40%20PM2820×2088 800 KB

2

885.15mm error indicates that there is an error in the DICOM series. You can use the DICOM module to inspect slice positions and find the offending file(s) as described here.

4

Hi Lassoan,
After I reopened the Slicer and loaded the DICOM data again. The image looked like normally, but the error information showed as following.

43%20AM
43%20AM2814×2088 898 KB

Here is the information about the CT data.

Thanks,
Xie

5

Hi @doc-xie - If my translator app is working right, then it’s telling me I need to login to download. Is there a way you can share a direct download link?

image
image496×544 26.6 KB

6

Hi Steve,
Sorry for the complicated precess. I have uploaded the file successfully into Onedrive and sharing with you now.
https://1drv.ms/x/s!AkUOMHTR1-SrcQ_bXr3B3D3c8Mk
Thanks,
Xie

7

Hi Lassoan,
I have uploaded the file successfully into Onedrive and sharing with you now.
https://1drv.ms/x/s!AkUOMHTR1-SrcQ_bXr3B3D3c8Mk
Thanks,
Xie

8

Hi @doc-xie -

I believe @lassoan was thinking that you could type “Image” into the metadata filter field so that only the ImageOrientationPatient and ImagePositionPatient fields would show up and then it’s possible to quickly scroll through all of the image files and see how the numbers are changing. In particular for an axial CT it’s the last number in the ImagePositionPatient that determines the relative locations of the slices and they should be smoothly incrementing slice by slice, but maybe they are not for this dataset. If you find slice that appear out of place you could remove those from the directory and then try re-importing. When you see an issue with irregular geometry and a very large error it can mean that there are missing slices or extra slices that throw off the computation and lead to the unusually large bounding box like in your first screenshot. Unfortunately as Andras mentioned it probably means the data is non-standard in some way we can’t automatically account for. If you find a way to share an anonymized copy that still exhibits this error we could look more closely.