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

Handling file meta information with incorrect length #158

Open
dgobbi opened this issue Oct 5, 2018 · 0 comments
Open

Handling file meta information with incorrect length #158

dgobbi opened this issue Oct 5, 2018 · 0 comments

Comments

@dgobbi
Copy link
Owner

dgobbi commented Oct 5, 2018

Apparently some DICOM files have an incorrect FileMetaInformationGroupLength, and this can cause vtkDICOMParser to fail. The specific reason for the failure is that when vtkDICOMParser thinks it has reached the end of the meta-header, it switches from ExplicitLittleEndian to the data set transfer syntax (e.g. to ImplicitLittleEndian, if that was requested). If it reads Explicit as Implicit, then the VR is interpreted as part of the element length, and parsing of the data set fails.

Note that for the files where I saw this problem (which are anonymized and of unknown provenance), the FileMetaInformationGroupLength was the length minus the private section at the end.

There are a few ways that this could be solved. Note that this seems to be a very rare problem, so I don't consider it to be a high priority to fix. It's a 'nice to have'.

  1. Instead of using FileMetaInformationGroupLength, the parser could read until a group element other than 0002 was found (this would require peeking 2 bytes ahead).

  2. If the parser encounters group 0002 elements while reading the data set, they could be read as explicit regardless of the data set transfer syntax. This would eliminate the need to peek ahead, but adding the extra check will complicate the parser code.

  3. Add better general-purpose code for handling cases where explicit VR data elements are present in an implicit VR data set. This also complicates the code, but it could add to the overall robustness of the parser if done right.

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

1 participant