Philips enhanced DICOM #144
Comments
|
I notice that dcm2niigui (2 November 2010) correctly deals with these files. On the output there is a line: Swizzling: XYTZ -> XYZT which presumably isn't happening with dcm2niix. |
|
I do not have access to a Philips system. Can you send me a dropbox link to a sample image - feel free to use my personal email address. |
|
Thanks for the sample. Does the problem occur with the raw DICOM images, or only the images that have been processed by Osirix? It looks like Osirix had a hard time interpretting this 4D dataset. I would be grateful if you could send me a DICOM image straight from the scanner. |
|
Please compile and test the latest version (v1.0.20171122). The issue is that your sample image used implicit Value Representations (VRs) and hid some vital data inside SQ VRs (sequence of items). The new code is a little bit slower at converting Philips images saved with implicit VR. However, it should accurately decipher details buried inside the header. This will require thorough testing with Philips data to ensure there are no unintended consequences. I detect the manufacturer so there should be no penalty or dangers with data from other vendors. If you want to convert your images with the stable releases of my software, you can simply convert them to explicit VR: |
|
Excellent thanks! I have a feeling that our research PACS converts explicit VRs to implicit - so that's probaly why you might not have come across this before. Thier argument is that all SCPs must support implicit VRs - so it's a sensible thing to do (I'm not so sure!). I'll be sure to get you some data straight from the scanner for testing purposes... |
|
Data directly from scanner: Data from scanner > pukka-j pacs > horos: |
|
Latest version deals with the data correctly, thanks. |
|
I will close this issue as it is fixed with the latest version. The data from your scanner is explicit VR, while your PACS is saving it as implicit VR. In theory, dcm2niix (and other tools) should handle implicit VR. However, with very complicated files like this where data is nested in SQs, I would recommend sticking with explicit VR. I note that Jolinda's terrific MRIConvert also has problems with your implicit images, and I suspect other tools will be confused as well. |
|
Hi, Unfortunately the previous example I sent was a unusual case (scanner > pacs > osirix) and the more usual case (scanner > pacs) has problems for fmri and DTI data. I've included some test data (T1, fMRI, standard DTI and DTI with custom directions) directly from the scanner and from pacs: https://www.dropbox.com/s/44ejsolkxi9hkcd/TO_CHRIS_R.zip?dl=0 Obviously this is an unusual (and possibly pacs vendor specific) issue, but if you do find time to fix it we'd be very appreciative! I've included all the sequence details in the zip but please get in touch if you need further information. Martin |
|
We are also having slice ordering problems for the fMRI and DTI data in PAR/REC format - same data as the previous message: |
|
Martin- |
|
This is a summary of what isn't working: |
|
Can you help describe your comment " (x-dirns are -ve compared to Philips output)" - perhaps scanning the phantom with a fiducial marker on the "patient's" left side would help. I assume you mean that left and right are defined differently in DICOM and NIfTI space. In DICOM space the X coordinate increases as you move leftward, while in NIfTI space the X coordinate increases as you move rightward |
|
Yes, this refers to the bvec values - which are negative for the x-direction compared to how Philips define them. I assumed this was for good reason (which is why they are labelled ok) - but it's good to know this is likely down Philips defining their directions in the DICOM convention. |
|
I now generate a clear error message for your PAR/REC fMRI sequence. This sequence has two issues: first the volumes are not saved sequentially to disk, rather the order of the 50 volumes is 1, 5-50, 2-4. Second, the order of slices within the volumes changes. For volume 1 the slices are saved as two ascending sets (17-32, 1-16) while for the other volumes they are saved in descending fashion (32-1). In theory my code could be adapted to handle this, and I am happy to test any patches. More practically, this seems like an issue with the software that created these scans and should be fixed by the vendor. A simple solution would be to modify my nii_rescue_par script to handle these situations. If anyone wants to submit a revised version I would be happy to test it. For the moment, the program detects these corrupted scans and reports the issue. |
|
Same issue with PAR/REC diffusion scans, the first volume of 48 slices (diffusion b value number = 1) is saved as the first 48 slices on disk, but a different ordering is used for subsequent volumes. This issue is now clearly reported to the user. |
|
Hello, the current version will now support your Philips DICOM data both from the scanner and after they have been converted to implicit VR by your PACS system. However, I want to say that this is a kludge, as these images are not valid DICOM images. Specifically, every slice of your image includes two contradictory values for Patient Position 0020,0032. We have seen this violation since R3.2, and it is discouraging to see it still exists in R5.2. If Philips wants a different definition of patient position, they should use a private tag. Please contact your vendor and ask them to honor their DICOM conformance statement. The current version does not handle PAR/REC files where the slice order changes between volumes, but it does detect these anomalies and will prompt the user to use dicm2nii (which will handle these). If anyone wants to devote the development time to support these, they can generate a pull request. |
|
Many thanks for the fix. Just to clarify, is the DICOM violation present in the data exported directly from the scanner; the data from PACS or both? Martin |
|
The problem is with the raw Philips data (which is saved as explicit VR format). Since this has been around since at least R.3.2.2, we have a kludge that detects multiple patient positions. I have now extended this kludge to handle implicit VR. However, the problem is with the raw data coming from your scanner: they violate the DICOM standard. Since Philips provides a DICOM conformance statement, they have an obligation to provide DICOM-compatible images. The definition of 0020,0032 is very clear. Having two contradictory patient positions for the same image is not allowed. |
|
Ok, I’ll pass that on to our local Philips rep. |
* commit 'v1.0.20171215-8-g82b9210': (35 commits) Save defaults even if no input images rordenlab#152 Option to read, read&write or just write options rordenlab#152 Removing compiler flag to ignore deprecation of "register" in C++ Removing defunct register keyword from C++ code Argument -g generates default files only when requested rordenlab#152 fixed one of the links, and added NeuroDebian pointer Faster conversion when opts.numSeries != 0 Check if dcm2niix is latest stable release ("dcm2niix -u", Unix only) Update version notes Support implicitVR with two positions per image rordenlab#144 mod: change new line characters to _ in the dcmStr function Detect if PAR DTI volumes are sequential and slice order is consistent rordenlab#144 Detect if PAR volumes are sequential and slice order is consistent rordenlab#144 Typo Typo New command line option allowing user to extract specific data series by number. Release new version (v1.0.20171204) Support CLANG/LLVM and XCode conventions (e.g. classes only in *.hpp not *.h) Restores non-debugging compiler flags Converts TVolumeDiffusion from a class to a struct ...
Hi,
I'm having problems converting some Philips fMRI data from enhanced DICOM to nifti format. Firstly, the dimensions seem to be incorrectly ordered so the images do not display correctly. Secondly, I'm getting the following messages when converting:
Unable to determine spatial orientation: 0020,0037 missing!
Unable to determine spatial orientation: 0020,0037 missing!
Unable to determine spatial orientation: 0020,0037 missing!
Warning: Unable to determine slice direction: please check whether slices are flipped
Warning: Bogus spatial matrix (perhaps non-spatial image): inspect spatial orientation
I checked the file with dcmdump (from dcmtk) and was able to find the 0200,0037 tag, but it's well hidden. I've attached the relevant section of the output with the last line showing the tag. This structure is repeated many times throughout the file, but I think you're safe to assume they should all be the same as the first occurrence. Happy to send example data if you need it.
Thanks for an excellent tool,
Martin
dcm_dump.txt
The text was updated successfully, but these errors were encountered: