dcmqi: E: PatientName (0010,0010) violates VR definition in PatientModule but actual value is correct
Dear developers,
I am trying to create the structure report of a white matter hyper-intensity lesion segmentation with your docker container but no matter the Patient’s Name I always get the same error (see below). The actual value is “N2D_PATIENT”, but also tried with “xxx xxx” with the same result.
I can share the data with you, just let me know if you need it and I upload it.
Thank you very much. Miguel.
docker run -v /Users/miguel/Workspace/RAPIDS/SR/dcmqi_test:/tmp/dcmqi qiicr/dcmqi itkimage2segimage --inputDICOMDirectory /tmp/dcmqi/input_data --inputMetadata /tmp/dcmqi/wmh_segmentation.json --inputImageList /tmp/dcmqi/output_nifti/18991230_000000nifti2dicom044s001a001.nii.gz --outputDICOM /tmp/dcmqi/wmh_segmentation.dcm
dcmqi repository URL: git@github.com:QIICR/dcmqi.git revision: 72869c3 tag: latest-2-g72869c3
Searching recursively /tmp/dcmqi/input_data for DICOM files
Input image size: [240, 240, 48]
W: PatientName (0010,0010) violates VR definition in PatientModule
W: PatientSex (0010,0040) violates VR definition in PatientModule
W: AccessionNumber (0008,0050) violates VR definition in GeneralStudyModule
W: InstitutionName (0008,0080) violates VR definition in GeneralEquipmentModule
W: PatientAge (0010,1010) violates VR definition in PatientStudyModule
W: PositionReferenceIndicator (0020,1040) absent in FrameOfReferenceModule (type 2)
Directions: 0.997303 -0.0502721 -0.0534678
-0.0229997 -0.905936 0.422789
0.0696929 0.42042 0.904649
Processing input label Image (0x1889550)
RTTI typeinfo: itk::Image<short, 3u>
Reference Count: 3
Modified Time: 184
Debug: Off
Object Name:
Observers:
none
Source: (none)
Source output name: (none)
Release Data: Off
Data Released: False
Global Release Data: Off
PipelineMTime: 48
UpdateMTime: 183
RealTimeStamp: 0 seconds
LargestPossibleRegion:
Dimension: 3
Index: [0, 0, 0]
Size: [240, 240, 48]
BufferedRegion:
Dimension: 3
Index: [0, 0, 0]
Size: [240, 240, 48]
RequestedRegion:
Dimension: 3
Index: [0, 0, 0]
Size: [240, 240, 48]
Spacing: [0.958333, 0.958333, 3]
Origin: [-107.096, 80.3152, -82.9768]
Direction:
0.997303 -0.0502721 -0.0534678
-0.0229997 -0.905936 0.422789
0.0696929 0.42042 0.904649
IndexToPointMatrix:
0.955749 -0.0481774 -0.160403
-0.0220414 -0.868189 1.26837
0.066789 0.402902 2.71395
PointToIndexMatrix:
1.04066 -0.0239997 0.072723
-0.0524578 -0.945325 0.438699
-0.0178226 0.14093 0.30155
Inverse Direction:
0.997303 -0.0229997 0.0696929
-0.0502721 -0.905936 0.42042
-0.0534678 0.422789 0.904649
PixelContainer:
ImportImageContainer (0x1884ec0)
RTTI typeinfo: itk::ImportImageContainer<unsigned long, short>
Reference Count: 1
Modified Time: 180
Debug: Off
Object Name:
Observers:
none
Pointer: 0x7f569bb8a010
Container manages memory: true
Size: 2764800
Capacity: 2764800
Found 2 label(s)
Skipping label 0
Processing label 1
Total non-empty slices that will be encoded in SEG for label 1 is 48
(inclusive from 0 to 48)
E: PatientName (0010,0010) violates VR definition in PatientModule
FATAL ERROR: Writing of the SEG dataset failed! Please report the problem to the developers, ideally accompanied by a de-identified dataset allowing to reproduce the problem!
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 36 (32 by maintainers)
This issue was copied to https://discourse.slicer.org/t/e-patientname-0010-0010-violates-vr-definition-in-patientmodule-but-actual-value-is-correct/3737
@jcfr never mind - I was able to edit your message on discourse (!) to add that link myself!
By the way, this is a great discussion, which will be difficult to find later. Should we migrate this discussion to Slicer forum or somewhere else with better visibility?
I agree. My point is that based sharing solutions to common problems lowers the development and maintenance workload in the long term (more time is saved than the overhead of coordination between different groups). If you just let everybody do what feels convenient, the easy 90% of the code is reimplemented many times, and the difficult 10% has partial implementation in random toolkits. Eventually, a few well-designed, full-featured solutions emerge as winners, but this process can be accelerated with some conscious effort.
I agree, monolithic tools are not well suited for this. The problem exactly is that various groups maintain their own monolithic tools, with zero modularity and potential for reuse or customization. Instead, we should have a small common framework that many groups are using and contributing to - with shared infrastructure components (such as tilted gantry, variable image slice spacing, patient name, etc. management) and application-specific plugins (that can handle import/export of a particular DICOM IOD).
We’ve fixed CTK to have a full-featured interaction Python console, even on Windows. It works really well! However, these developments have not been merged yet . @jcfr could you please merge the pull requests and update Slicer master?
It would be great to factor out the code in slicer so that it could be used in other scenarios in addition to the slicer gui. We already do this for things like the diffusion plugin that uses DWIConvert under the hood or QuantitativeReporting that uses dcmqi.
Regarding your other points Andrey, while they are generally true I don’t see things like package size or startup time as limiting factors. Converting files like this is not a real time activity and if you have a large number of dicom files to convert slicer is the least of your disk space concerns. No reason to prematurely optimize something like this.
I believe that having so many simple, rigid, single-purpose dicomToX tools is bad, because these tools hide issues (by making random assumptions and ignore various potential problems) and cause fragmentation in the research community. It would be better to establish one common DICOM import/export tool framework that many people can use, customize, and extend.
I agree with your list of limitations above (although maybe the recently completed PythonSlicer interpreter solved some of these issues). This common DICOM converter framework does not have to be Slicer-based. However, it should be general, customizable, and extensible, similarly to Slicer’s DICOM import/export infrastructure.
Andras, I agree with you, but scripting Slicer functionality in python, and running the result in batch mode has a very big startup overhead, and is associated with other inconveniences, such as tricks that need to be done for headless mode, large package size, platform-specific launcher issues. It might be a lot more convenient for users to use command line tools that are designed for the specific task (when they are available!) instead of learning how to write Slicer scripts, and then figuring other issues.
I am all for Slicer, as you know, but for example using Slicer for batch conversion of DICOM from command line is extremely slow and not convenient, so for that task I would rather use plastimatch, dcm2niix, or dicom2nifti, which are all maintained, and do the job well and much more efficiently.
In this particular case, indeed, if nifti2dicom is not supported (there has not been much activity, and I am not sure about the quality of the code), Slicer might be the only option.
You can use all Slicer features in batch mode, without GUI. If you ever need help in figuring out how to access a particular feature then ask on the Slicer forum.
“nifti2dicom” has a very narrow scope - it can only export a single 3D image volume. DICOM storage is much more than this. You may need to export segmentation objects, RT structure sets, registration objects, structured reports, complete studies with references between series, etc. Slicer can all do all this, using an extensible, plugin-based DICOM export infrastructure. It’s far from perfect, but it’s being continuously improved.