Keyword 'DICM' not found in the header (file offset 132) about dicom HOT 9 CLOSED

@suyashkumar I've provided some test files from the dicom4android repo that I was able to reproduce this error with. They appear to have problems in addition to this error (for example, some are missing the header data and thus would invoke issue 53 because that tag wouldn't be there). However, we have DICOMs that conform to the standard except in the way described in this issue.

issue59.zip

from dicom.

Hm, this is an interesting one. Checking for this magic word is a good way to ensure you're actually reading a DICOM and that it isn't malformed. One option we can provide is a force option or flag that will not hard fail on this check, but might fail in other ways downstream since we don't have this magic word.

from dicom.

@suyashkumar As a potential fix like you described above, what do you think about:

1. Adding a force boolean to the parser struct which can be set through a setter function (or directly, whichever is preferred)
2. Adding a default value of the force boolean as false with something like this implementation
3. Adding an && p.force == false case the if statement that throws the 'header not found' error, or some logic to log it as a non fatal error and not return. For example, inside of the if statement above, something like:
   if s := p.decoder.ReadString(4); s != "DICM" { if p.force { log error and continue } else { fatal error and return } }

from dicom.

@IChocked this approach seems reasonable to me, and thank you for raising this issue.

Regarding the default false value, the zero values for booleans is false anyway, so just adding it to the struct should be fine.

Note the following code after that if statement expects that the other preamble tags appear in a certain order. If this is not the case, that may lead to failures as well.

@IChocked are you interested in submitting a PR for this? If not I can take care of it as well!

from dicom.

@suyashkumar Yeah, I'd definitely be interested in submitting a PR for this! I'll get on it and submit something as soon as I can

from dicom.

@IChocked do you have a data citation for the files you uploaded earlier? I'd like to include them in the testfiles for this repo if possible :).

I think I have a semi-elegant fix for this in the v1.0 API

from dicom.

cc: @wkoszek in case you may have the citation handy

from dicom.

@suyashkumar We don't know where https://github.com/dragonlet/dicom4android took them from. I found this repo by accident, and it happened to have the exact same problem as the problem we had experienced in production.

from dicom.

Closing this out due to the fixes in #127. Let me know if we're missing anything here!

from dicom.