Here you have, thank you
https://drive.google.com/open?id=1GiTakTBuGFdb-joN_IesZxVAQMM9NiW-
Thank you @laura_rodriguez, this is helpful.
The underlying issue appears to be that GDCM does not recognize the private class UID and issues a warning:
Warning: In /Users/pieper/slicer4/latest/Slicer-superbuild/ITKv4/Modules/ThirdParty/GDCM/src/gdcm/Source/DataStructureAndEncodingDefinition/gdcmFileMetaInformation.cxx, line 874, function gdcm::MediaStorage gdcm::FileMetaInformation::GetMediaStorage() const
Media Storage Class UID: 1.2.276.0.7230010.3.1.0.1
Searching for that class UID leads to this issue: https://sourceforge.net/p/gdcm/feature-requests/15/
Which indicates this data was somehow manipulated and re-saved using DCMTK.
So as a workaround for this data @laura_rodriguez you can go to the Slicer’s Edit menu and pick application settings and then in the DICOM page set “DICOM reader approach” to be DCMTK. I just confirmed that this loads with the correct spacings.
As another option I loaded with a recent version of Slicer (post 4.8) that includes the “Acquisition Transform” feature (the one described above to correct gantry tilt) using GDCM it loads with spacing 1,1,1 but the transform reassuringly actually gives the exact same image, which is a good confirmation of that approach.
Getting back to the original issue, the current default mode is “GDCM with DCMTK fallback” which is meant to handle the case where GDCM fails to load at all, e.g. by throwing an exception. Here it just prints a warning and then incorrectly loads. It seems to me that ignoring the image spacing should be a GDCM failure and not just a warning.
Thank you, I will try all that and tell you
Looking at this a bit more, it’s clear that these are pretty non-standard files.
Running @dclunie’s verifier points out that the file is internally inconsistent.
$ dciodvfy /tmp/3dslicer\ test/Ferrassie\ 1-MbsSup.0135.dcm
...
Error - Media Storage SOP Class UID different from SOP Class UID
...
The media class is the DCMTK private class while the image SOP class is Secondary Capture. Because of this GDCM looks for spacing in tag 0x0018,0x2010 while the file actually has it in 0x0028,0x0030.
I guess the best for you @laura_rodriguez might be to look into the history of these files and see if any of the DICOM information can be relied on. If not maybe save them in a less ambiguous way, either as fixed DICOM or maybe in nrrd or similar format.
For the record some of the related GDCM code is linked below.
@pieper Should we add dclunie’s verifier to Slicer? We could launch it from DICOM patcher or the DICOM importer or browser.
@laura_rodriguez Let us know if you figure out what’s the origin of these files. If they are produced by a commercial software then we may add a rule to our DICOM patcher module to fix it up.
That’s an interesting idea - here’s the info on the tool DICOM Validator - dciodvfy
It’s part of David’s older C++ toolkit but all his newer work is in Java (but I don’t think he has anything comparable to dciodvfy in that and we wouldn’t want a Java dependency). But I do like the idea of giving users more options for how to work with troublesome data since it happens fairly often.
This would be great!
I don’t think there is a replacement in the Java tools for dciodvfy.
Note that dicom3tools is not cmake-fied, it relies on ‘nmake’. Another challenge is that by intent the project is not a “two-way open source”. David makes the source code available for everyone’s use, but whatever changes you do to the source code (e.g., cmake-fy it), will not be integrated into David’s master, so the process will require a lot of maintenance.
A practical workaround could be to use dciodvfy from a docker container (we already have a precedent for docker prerequisite in an extension).
I like the idea of dciodvfy in a docker as a debugging utility. But installing docker is still a bit of a hurdle.
Agreed!
I remember being criticized when I made a similar comment in the past! 
Sorry for the delay in the my answer, but I had to lecture these two days.
I think they were modified by avizo:
Thank you
L
Hello,Steve!
A new problem with the distorted image. After I load the DICOM data into the software,the image was distorted even if with the software of 4.9 version,and the value of the Gantrytilt can not be found in the metadata.
I cannot find the reason and solve the problem.
Best wishes!
doc-xie
Please try with today’s nightly build. If does not work with default settings, check “Advanced” checkbox and try each loadable.
If none of these are enough then run it through DICOM Patcher module, import it again (if you don’t generate new IDs then you have to delete the previously imported items from the DICOM browser), and see if you can load it (with default or advanced settings).
If none of these work, then use the original CT, that was not manipulated by Avizo, or try an updated version of Avizo - hopefully they have figured out they exported invalid DICOM files and fixed their problem. If you can process a non-confidential data set the same way then we can create an error report from that that you can send to Avizo.
Thanks very much, Professor Lassoan!
The distorted images were adjusted normally after loaded the DICOM files into the newly version 3D Slicer.But as for the data I used before(Aug 4),the images have not any changes,should I correct it with the value of the GantryTilt like before?
Best wishes!
doc-xie
I would recommend to use the latest version of Slicer (and re-process any data that you processed with earlier version of Slicer). Don’t use GantryTilt value - it is for informational purposes only, not for processing your volumes. If you need to process the volumes then I would suggest to resample them on a rectilinear grid using Crop Volume module.
Hello,professor Lassoan!
Another distorted image need to be corrected!
The results of the volume rendering did not accord with the yellow slice
Even if I reconstructed the skull with Editor module,the results was the same as before.
So,how to evaluate the tilt degree of this volume and correct the imaging!
Have a goog weekend!
Doc-xie.
Volume rendering cannot apply non-linear transforms on-the-fly. You need to harden the non-linear transform in order to take it into account for volume rendering.
Hi Steve,
I have been trying to understand the gantry tilt problem too. Thank you for this detailed explanation here, but according to my understanding, the shear correction should be applied in the z-direction and is the tangent of the shear. This supplement describes it better.
I understand that the idea is to move the superior coordinate as a function of the anterior coordinate, but I am not able to consolidate the transform you specify to what the article describes. Could you please comment on this?
Thank you,
Sharada
I’m afraid the link you provided has expired - maybe you can repost?
In any event yes, you could represent gantry tilt as a shear transform, with a non-zero element in the off-diagonal of a linear transform as described in some of the earlier posts in this thread.
But it’s easier and more general to enable the geometry correction in the DICOM page of the Application Settings (described here).
Hi Steve,
Thank you for your response. I made some progress.
The link has expired for some reason, but here’s a screenshot from it:
I see that in an earlier explanation you had sin(gantry_tilt) in T(2,3) instead of the transformation described here.
I am not sure how/why it is different from the one described in the screenshot. Can you please explain?
I also had a similar question - when obliquely acquired sagittal images are loaded, Slicer visualizes the geometry correctly. But is there a way to re-slice the volume such that the geometry is the normal sagittal orientation? ([[0,0-1],[1,0,0],[0,-1,0]]). Please let me know!
Best,
Sharada
I’d suggestion going with the s*tan(alpha) formula if that’s been published and validated. My post was just an experiment that looked correct but didn’t take slice spacing into account and maybe it just looked close.
But as I pointed out, we use a different method in Slicer that handles both gantry tilt and variable slice spacing since both are very common. I’m pretty confident in this nonlinear transform approach so I’d suggest that rather than trying to work out the matrix.
Yes, Slicer takes into account the acquisition orientation (see here for more details). You can always resample to a different grid if you want, for example with the Resample Scalar/Vector/DWI Volume module, but it’s usually better to leave them in the native space to avoid lossy resampling.