Unexpected DICOM element in current reading position

[ibaryshnikov]

There are some cases which produce this error. The transfer syntax is 1.2.840.10008.1.2.4.70. I'd be happy to help fixing it

[neandrake]

That transfer syntax is "JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression". My guess is support for decoding pixel data with that transfer sytnax is not yet supported.

[Enet4]

Decoding the pixel data is meant to be an orthogonal capability to that of decoding the data set. In other words, while the library does not know how to interpret the pixel data without the necessary decoder, it would still be able to load the DICOM file and fetch each attribute in its raw, possibly encoded form.

With that said, I suspect that the parser may be having trouble delimiting the pixel data attribute, but I can only be sure with a reproducible example. Can you construct an equivalent file that can be freely disclosed?

[ibaryshnikov]

Can you construct an equivalent file that can be freely disclosed?

I'd be happy to. Is there any tool which can create .dcm files with arbitrary transfer syntaxes?

[ibaryshnikov]

Found some online examples
https://barre.dev/medical/samples/#XA-MONO2-8-12x-catheter
The one named as XA-MONO2-8-12x-catheter has 1.2.840.10008.1.2.4.70 transfer syntax and can be downloaded from https://www.dropbox.com/s/k7obz27f07z1kmk/XA-MONO2-8-12x-catheter.gz?dl=0
Currently fails with TextEncodingError("Invalid date value element \"1994.10.16\"")

[Enet4]

The date 1994.10.16 is not DICOM compliant (it was before in ACR-NEMA Standard 300): the components should not be dot separated, and the current behavior in 0.1.0 is to attempt to parse all date values while reading the full DICOM data set. This behavior will change with #12, but it will still be unable to turn that text element into a binary date value.

[ibaryshnikov]

I was looking for an example of .dcm file with transfer syntax 1.2.840.10008.1.2.4.70, it's the only one I found. Sadly, error with the date occurs before the actual error we need to reproduce. @Enet4 is there a known way to produce a .dcm with such TS?

[neandrake]

Here are two example images using this transfer syntax
images.zip

I found these in the Grassroots DICOM repository:
https://sourceforge.net/projects/gdcm/files/

[ibaryshnikov]

@neandrake thanks! I've tested them,
ACUSON-24-YBR_FULL-RLE-b_dcmdrle_dcmcjpeg.dcm produces ReadValue(UnresolvedValueLength)
and
PHILIPS_Gyroscan-12-MONO2-Jpeg_Lossless.dcm - DataSetSyntax(UnexpectedToken(ItemEnd))

[neandrake]

Additionally you could use a tool like dcmtk to modify your original dicom to modify the date element with the incorrect format.

[Enet4]

After a fresh read of this thread, I conclude that:

• The first indicated issue with the unsupported transfer syntax was due to the encapsulated pixel data, which has been resolved in Data set level reading and writing of encapsulated pixel data #42.
• The second issue was a bug when parsing items and sequences with an explicit length, which has been fixed in Reading PixelData of undefined length #30.
• The other problem with non-compliant DICOM values stopping the parser is already tracked in Interpreting string-based values? #9.

As such, I believe we can close this one. Please file another issue if you find a new problem.