Improve support for non-compliant DICOM and edge cases about dicom HOT 7 OPEN

The draft changes in #330 address 1 and 2.

from dicom.

For missing metadata group length we do hav a flag for that, but can consider automatic fallback behavior:

dicom/read.go

Line 184 in 65259e5

if !r.opts.allowMissingMetaElementGroupLength {

I think originally the idea was the safest option is to force callers to be as explicit as possible about what loosened restrictions they may want in case there are any safety issues with fallback behavior or in case the fact the dicom is not compliant is something the user would want raised to them (in case that led to other concerns). That being said, recently I've been thinking it's more reasonable to just have more automatic fallbacks, at least ones that are "standard" in the industry for dicom non-compliance.

I agree. I think it's better to have these automatic fallbacks and just log warnings if non-compliant things are found. That's the behavior most libraries choose I believe.

from dicom.

Edited the original comment to update current status, link to PRs, etc.

from dicom.

Thanks @lnogueir! I agree that we can attempt some enhanced fallback behavior, particularly if that's standard practice in other parsers. Our current fallback behavior for no transfer syntax found in the Metadata is to proceed with little endian implicit but it shouldn't be too difficult to try a couple different transfer syntaxes speculatively.

from dicom.

For missing metadata group length we do hav a flag for that, but can consider automatic fallback behavior:

I think originally the idea was the safest option is to force callers to be as explicit as possible about what loosened restrictions they may want in case there are any safety issues with fallback behavior or in case the fact the dicom is not compliant is something the user would want raised to them (in case that led to other concerns). That being said, recently I've been thinking it's more reasonable to just have more automatic fallbacks, at least ones that are "standard" in the industry for dicom non-compliance.

from dicom.

Going through these in a little more detail, and adding some more notes:

1. Easy fix (have working locally)
2. Easy fix (have working locally)
3. This appears to parse fine, but iiuc the problem is the PixelData is intentionally truncated? So the vl says 8192 but there aren't that many bytes left in the dicom. We treat this as an error, which seems reasonable imo but we can discuss more.
4. Bug/implementation needed with UN unknown sequences
5. Needs more investigation, seems related to the UN sequences / tags possibly similar to 4.
6. Also seems possible related to UN sequences / tag handling
7. Same as 4/5/6 at first glance?
8. Should parse fine with allowMissingMetaElementGroupLength but need to check

from dicom.

Also, the changes in #331 address 6 (with SkipPixelData). They almost address 4 but some other changes are still needed for that.

from dicom.