You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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'.
Instead of using FileMetaInformationGroupLength, the parser could read until a group element other than 0002 was found (this would require peeking 2 bytes ahead).
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.
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.
The text was updated successfully, but these errors were encountered:
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'.
Instead of using FileMetaInformationGroupLength, the parser could read until a group element other than 0002 was found (this would require peeking 2 bytes ahead).
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.
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.
The text was updated successfully, but these errors were encountered: