DICOM.jl icon indicating copy to clipboard operation
DICOM.jl copied to clipboard

dcm_write bug

Open AaronGhost opened this issue 1 month ago • 0 comments

Thanks for writing this package

I have had some issues with writing back some DICOM image leading to the written image not being a valid DICOM anymore when a tag can be expressed with multiple vr, they are all written back instead of picking one.

For example, for (0x0040, 0x9211), the standard authorises either a VR of US or SS. In dcm_dict.jl, the data is set to:

(0x0040, 0x9211) => [:RealWorldValueLastValueMapped, "US or SS", "1"]

When writing, the VR is then set to "US or SS" overflowing on the length of the parameter. Further reads therefore try to read an incorrect amount of data, leading to an error.

Steps to reproduce:

using DICOM
io = IOBuffer();
DICOM.write_element(io, (0x0040, 0x9211), 0x0fff, true, Dict{Tuple{UInt16, UInt16}, String}());
seek(io, 0);
read(io, String) # Show the overflow
seek(io, 0);
dcmdata = DICOM.DICOMData(Dict{Tuple{UInt16, UInt16}, Any}(), :little, true, Dict{Tuple{UInt16, UInt16}, String}());
DICOM.read_element(io, dcmdata)

Result:

"@\0\x11\x92US or SS\x02\0\xff\x0f"
ERROR: EOFError: read end of file
Stacktrace:
 [1] peek
   @ Base .\iobuffer.jl:185 [inlined]
 [2] read(from::IOBuffer, T::Type{UInt16})
   @ Base .\iobuffer.jl:195
 [3] numeric_parse(st::IOBuffer, T::DataType, sz::UInt16, endian::Symbol)
   @ DICOM D:\Documents\Julia\DICOM.jl\src\DICOM.jl:351
 [4] read_element(st::IOBuffer, dcm::DICOM.DICOMData)
   @ DICOM D:\Documents\Julia\DICOM.jl\src\DICOM.jl:264
 [5] top-level scope
   @ REPL[88]:1

~~I can bypass this by using a custom VR value for the parameter, but it might be worth putting a fix in the library.~~. It is not easy to bypass as the custom vr is not passed to the sequence. I am happy to put a PR together depending on the wanted solution.

(also the DX_Implicit_Little_Interleaved.dcm dataset used for testing does not exist anymore).

AaronGhost avatar May 16 '24 14:05 AaronGhost