Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manufacturer tag not found, but appears in DICOM #487

Closed
lidialuq opened this issue Mar 4, 2021 · 5 comments
Closed

Manufacturer tag not found, but appears in DICOM #487

lidialuq opened this issue Mar 4, 2021 · 5 comments

Comments

@lidialuq
Copy link

lidialuq commented Mar 4, 2021

When the manufacturer tag (0008, 0070) is set to "GE MEDICAL SYSTEMS" or "SIEMENS", dcm2niix cannot find the manufacturer, and I get the warning "Unable to determine manufacturer (0008,0070), so conversion is not tuned for vendor". In the json files though, the Manufacturers Model Name tag is filled ("Avanto", for example). On the other hand, everything works fine when manufacturer tag is "Philips Medival Systems" (no warning, relevant tags in json are filled).
The dicom files I'm using come straight from PACS, and in principle should not have been changed in any way since they were created in the MRI machine. They are not anonymized in any way.

The command I run is dcm2niix -ba y -z y path/to/data. I use version v1.0.20201102 (64-bit Windows).

@lidialuq lidialuq changed the title Manufacturer tag not found, but appers in DICOM Manufacturer tag not found, but appears in DICOM Mar 4, 2021
@neurolabusc
Copy link
Collaborator

Avanto reflects the Manufacturer's Model Name (0008,1090) not the Manufacturer (0008,0070). My sense is that the Manufacturer tag has been mangled by your PACS system. Since each manufacturer interprets the complex DICOM standard differently and employs their own private tags, it is important to correctly identify the manufacturer that created the image. I suspect a DICOM anonymization stage or a PACS has mangled your data. If this is the case, this will impact any tool that attempts to decipher your data. Have you looked at the DICOM header with a tool like dcmdump or gdcmdump (alternatively, put a single DICOM file from your troublesome series in its own folder and convert with dcm2niix -b i -v 2 /path/to/DICOM/)? This will show the value stored in the Manufacturer tag. Alternatively, send a DropBox/GoogleDrive link to an example dataset to my personal email (shown in my avatar).

@lidialuq
Copy link
Author

lidialuq commented Mar 4, 2021

The Manufacturer tag is indeed empty in the dicom header as shown by running dcm2niix -b i -v 2 /path/to/DICOM/, but it is present in the original dicom header (see attached files, * are values that I have removed, but that are present in the original files). This is an issue for most of the series I want to convert (a few hundred), it seems like the only manufacturer that is found is Philips.
Is the reading of the Manufacturer tag by dcm2niix dependent on any other tags being present?

The images are not anonymized at all (they include patient name, for instance), but it might well be that PACS is messing up the header when storing the image (I know that agfa is one of the PACS systems used in the hospital network, though there are many others). Still, as long as the Manufacturer tag is present, it should in theory work..?

dcm2niix_header.txt
dicom_header.txt

@neurolabusc
Copy link
Collaborator

Looks like some tool inserted new sequence with a different Manufacturer (0008,0070) name. Your file dicom_header.txt only reports the highest level of the hierarchy.

(0018,A001) Contributing Equipment Sequence                 <Sequence of data>

@neurolabusc
Copy link
Collaborator

You may want to try the latest commit (v1.0.20210304) which is available as a compiled Windows application from AppVeyor. This gives precedence to the first Manufacturer tag that it recognizes (Siemens, Philips, GE, UIH, Toshiba, Canon, Bruker).

@lidialuq
Copy link
Author

lidialuq commented Mar 4, 2021

Neat, this fixed the issue. Thank you!

As a side note: It was apparently sectra inserting a new manufacturer in the Contributing Equipement Sequence tag (see image). The weird thing is that this tag is exaclty the same in all dicom files coming from this PACS. For some reason, dcm2niix still managed to figure out the manufacturer when it was philips, but not when it was siemens or GE.
contributing_equipement_sequence

yarikoptic added a commit to neurodebian/dcm2niix that referenced this issue Apr 6, 2021
* tag 'v1.0.20210317': (23 commits)
  CI: Travis updates submodules always from remote.
  Update dcm_qa_nih submodule.
  Remove diagnostic message
  help should describe accession number (rordenlab#496)
  Describe and provide kludge for mangled Canon DICOMs (rordenlab#495)
  Update Philips notes (rordenlab#493)
  Update dcm_qa submodule.
  Support Canon Enhanced DICOM (rordenlab#491)
  Use first recognized manufacturer tag (rordenlab#487)
  If mosaics where ANY volume is non-planar, save ALL volumes as 3D(rordenlab#481)
  Add notes
  Kludge to separate vNav files as 3D (rordenlab#481)
  Tell user to override merging (-m o) to separate coils, specific with fmrib usage that disrupts Siemens DCE processing (rordenlab#187)
  Forbid semicolon in filenames as Linux uses this for command concatenation and Windows function GetOpenFileName will truncate (rordenlab#425)
  report totalReadoutTime once
  EstimatedEffectiveEchoSpacing -> EffectiveEchoSpacing (rordenlab#480)
  GE Round factor for Total Readout Time
  Update explicit naming of DICOMs (rordenlab#252), GE file naming changes (rordenlab#476)
  Update issue templates
  GE TotalReadouTime, BEP009 fixes (rordenlab#476)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants