Open suever opened 9 years ago
From Dimitri....@gmail.com on June 25, 2014 07:42:47
This is obviously a known issue with some DICOM files, see this comp.protocols.dicom thread: http://fixunix.com/dicom/545185-dicom-file-without-file-meta-information-size-preamble.html Software such as DCMTK use an heuristic to guess the information usually found in the missing header.
From Dimitri....@gmail.com on June 25, 2014 23:04:47
I do understand the heuristic is hard to get right, so an implicit "force" might make matters worse.
If so let's make it a documentation suggestion. Unless I'm wrong there is nothing in the wiki about DICOM files without a header. A paragraph about missing preamble might help.
From Dimitri....@gmail.com on June 25, 2014 10:25:32
I am attempting to read DICOM files I have received from another lab. They were initially produced by a Siemens TrioTim MRI scanner running syngo MR B17.
An InvalidDicomError exception is raised whenever I attempt to read any of these files. Using "force=True" does fix the problem: dicom.read_file() succeeds and I can read tags such as SeriesDescription.
These DICOM files indeed miss a DICOM header and specifically the prefix "DICM" at position 0x80:
0000000: 0800 0500 0a00 0000 4953 4f5f 4952 2031 ........ISO_IR 1 0000010: 3030 0800 0800 2200 0000 4f52 4947 494e 00...."...ORIGIN 0000020: 414c 5c50 5249 4d41 5259 5c4d 5c4e 445c AL\PRIMARY\M\ND\ 0000030: 4e4f 524d 5c4d 4f53 4149 4320 0800 1200 NORM\MOSAIC .... 0000040: 0800 0000 3230 3133 3034 3232 0800 1300 ....20130422.... 0000050: 0e00 0000 3138 3136 3030 2e36 3837 3030 ....181600.68700 0000060: 3020 0800 1600 1a00 0000 312e 322e 3834 0 ........1.2.84 0000070: 302e 3130 3030 382e 352e 312e 342e 312e 0.10008.5.1.4.1. 0000080: 312e 3400 0800 1800 3400 0000 312e 332e 1.4.....4...1.3. 0000090: 3132 2e32 2e31 3130 372e 352e 322e 3332 12.2.1107.5.2.32
I understand the DICOM preamble is required in theory, but is sometimes missing in practice. The same files are read without problem by DicomBrowser or DCMTK's dcmdump. Is the default behavior of pydicom the proper one? Shouldn't pydicom be more forgiving by default?
Original issue: http://code.google.com/p/pydicom/issues/detail?id=149