Unexpected DICOM element in current reading position about dicom-rs HOT 10 CLOSED

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/

from dicom-rs.

@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))

from dicom-rs.

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.

from dicom-rs.

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?

from dicom-rs.

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?

from dicom-rs.

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\"")

from dicom-rs.

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.

from dicom-rs.

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?

from dicom-rs.

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

from dicom-rs.

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 #42.
• The second issue was a bug when parsing items and sequences with an explicit length, which has been fixed in #30.
• The other problem with non-compliant DICOM values stopping the parser is already tracked in #9.

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

from dicom-rs.