"corrupted Attributes BLOB" when an attribute uses an incorrect VR

[pitz-signalpet]

Describe the bug

When the first attribute in an attribute blob uses an incorrect VR, AttributeBlob.decodeAttributes throws a "not a DICOM stream" exception. This happens because the DicomInputStream.guessTransferSyntax logic validates the VR of the first attribute and fails if it does not match the dictionary:

: org.dcm4che3.io.DicomStreamException: Not a DICOM Stream
at org.dcm4che.core@5.33.1//org.dcm4che3.io.DicomInputStream.guessTransferSyntax(DicomInputStream.java:1120)
at org.dcm4che.core@5.33.1//org.dcm4che3.io.DicomInputStream.<init>(DicomInputStream.java:149)
at org.dcm4che.core@5.33.1//org.dcm4che3.io.DicomInputStream.<init>(DicomInputStream.java:144)
at deployment.dcm4chee-arc-ear-5.33.1-psql.ear//org.dcm4chee.arc.entity.AttributesBlob.decodeAttributes(AttributesBlob.java:124)
at deployment.dcm4chee-arc-ear-5.33.1-psql.ear//org.dcm4chee.arc.entity.AttributesBlob.getAttributes(AttributesBlob.java:91)
at deployment.dcm4chee-arc-ear-5.33.1-psql.ear//org.dcm4chee.arc.entity.Patient.getAttributes(Patient.java:360)

Not all DICOM equipment follows the standard to the letter. Our server received a study with attribute 0010,0010 (Patient's Name Attribute) having a "CS" VR. The study can't be properly retrieved from DCM4CHEE.

If I understand this correctly, there seems to be an easy fix. AttributeBlob.encodeAttributes always stores the attributes with ExplicitVRLittleEndian TS. If decodeAttributes specified the TS for DicomInputStream as well, guessTransferSyntax wouldn't be used and there wouldn't be an issue.

Expected behavior

DCM4CHEE should either handle the incorrect VR gracefully, or refuse to store the study in the first place.