DIMSE: Odd Fragment Length

Message

xcoder · #1 Post by **xcoder** » Mon, 2011-03-21, 12:44

Hi all

I have troubles with some DICOM files. At Line 1213 in dimse.cc there is a check for odd fragment length. If i comment this check out, everything works fine with my files.

Should this not only be a warning? (I know the DICOM Standard says, this should never be happen, but everything works fine...)

Glenn

#2 Post by **Jörg Riesmeier** » Tue, 2011-03-22, 21:45

Which DCMTK tool are you using or did you write your own application based on the DCMTK?

xcoder · #3 Post by **xcoder** » Wed, 2011-03-23, 10:26

I wrote my own application based on DCMTK.

But i think this code is also used in the dcmtk tools, isn't it?

Glenn

#4 Post by **Michael Onken** » Wed, 2011-03-23, 11:47

Hi Glenn,

tell us what you are exactly doing, this might help us understanding your problem. It seem that you are receiving (?) DICOM files. As the comment states in the code you pointed at:

Code: Select all

 /* check if the fragment length of the current PDV is odd. This should */
 /* never happen (see DICOM standard (year 2000) part 7, annex F) (or */
 /* the corresponding section in a later version of the standard.) */

So, obviously there seem to be somebody sending with odd fragment length in the PDVs, which is pretty low-level. This has nothing to do (probably) with your DICOM file but with the code encoding and sending these files.

I doubt that you use DCMTK for sending, or I assume you patched it in the wrong places, or, changed the receiving code. If all that is not the case, provide us with more information

Best regards,
Michael

P.S: Try to receive your files with DCMTK's storescp. If this does not work try to send your file from DCMTK's storescu to DCMTK's storescp.

xcoder · #5 Post by **xcoder** » Wed, 2011-03-23, 13:06

i use storescu for sending the DICOM file to the service. The service is self written and based on dcmtk.

Maybe i can anonymize the DICOM file and post it.

xcoder · #6 Post by **xcoder** » Wed, 2011-03-23, 13:46

ok i tested it with storescu/storescp

here is the output:

Q:\Products\Dependencies\Libraries\c\dcmtk\3.6.0\Windows\bin>storescu localhost 5000 test.dcm
W: DcmItem: Length of element (7fe0,0010) is odd
W: DIMSE Warning: (STORESCP,STORESCP): writeBlock Failed (Invalid stream)
E: Store Failed, file: test.dcm:
E: 0006:020e DIMSE Failed to send message
E: Store SCU Failed: 0006:020e DIMSE Failed to send message

Q:\Products\Dependencies\Libraries\c\dcmtk\3.6.0\Windows\bin>storescp 5000
W: DcmItem: Length of element (7fe0,0010) is odd
E: Store SCP Failed: 0006:0317 Peer aborted Association (or never connected)

#7 Post by **Michael Onken** » Wed, 2011-03-23, 17:21

Hi,

W: DcmItem: Length of element (7fe0,0010) is odd

Well, that seems to have nothing to do with your code line in dimse.cc, right?

Yes, it seems that the file has an error. In DICOM, every length field and its value has to have an even length, which seems to be violated in your file. So let's try to fix it:

1) What is happening if you just use dcmdump on that too? I guess you have the same error?
2) Try to use option +ae --assume-even-length (assume real length is one byte larger) and look whether it works.
3) If it does not work, try dcmdump option +Ep --ignore-parse-errors and see whether dcmdump is able to dump the file.
4) If you can parse through the file using above options, try to repair it using dcmconv: dcmconv inputfile.dcm outputfile.dcm --options where options are the options you have used above to dump the file correctly.

It could be that the file is totally defect, i.e. the length of element (7fe0,0010) (pixel data) is totally wrong. In that case, you may not have a chance to read the file with DCMTK without repairing it manually. You may send it to dicom at offis dot de, then we could tell you what is wrong with it and whether you have other options. Please try the above stuff first and tell us the outcome of each!

Best regards and good luck,
Michael

xcoder · #8 Post by **xcoder** » Mon, 2011-03-28, 13:07

I tested all options

here is the result:

./dcmdump /Volumes/Scratch/gga/dicom/test.dcm
I: DcmDataDictionary: Loading file: /Development/Products/Dependencies/Libraries/c/dcmtk/3.6.0/Mac/share/dcmtk/dicom.dic
W: DcmItem: Length of element (7fe0,0010) is odd

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 198 # 4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0002) UI =SecondaryCaptureImageStorage # 26, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.3.51.2.182.1.89.100.1.104.20110323.184659.315065] # 50, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianImplicit # 18, 1 TransferSyntaxUID
(0002,0012) UI [1.2.124.113532.1.1] # 18, 1 ImplementationClassUID
.....

./dcmdump +ae --assume-even-length /Volumes/Scratch/gga/dicom/test.dcm
I: DcmDataDictionary: Loading file: /Development/Products/Dependencies/Libraries/c/dcmtk/3.6.0/Mac/share/dcmtk/dicom.dic
W: DcmItem: Length of element (7fe0,0010) is odd
E: DcmElement: PixelData (7fe0,0010) larger (1869396) than remaining bytes (1869395) in file, premature end of stream

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 198 # 4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0002) UI =SecondaryCaptureImageStorage # 26, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.3.51.2.182.1.89.100.1.104.20110323.184659.315065] # 50, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianImplicit # 18, 1 TransferSyntaxUID
(0002,0012) UI [1.2.124.113532.1.1] # 18, 1 ImplementationClassUID
.......

./dcmdump +Ep --ignore-parse-errors /Volumes/Scratch/gga/dicom/test.dcm
I: DcmDataDictionary: Loading file: /Development/Products/Dependencies/Libraries/c/dcmtk/3.6.0/Mac/share/dcmtk/dicom.dic
W: DcmItem: Length of element (7fe0,0010) is odd

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 198 # 4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0002) UI =SecondaryCaptureImageStorage # 26, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.3.51.2.182.1.89.100.1.104.20110323.184659.315065] # 50, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianImplicit # 18, 1 TransferSyntaxUID
(0002,0012) UI [1.2.124.113532.1.1] # 18, 1 ImplementationClassUID
.....

(because of the size of the dump i replaces the trailing lines with ....)

Parsing looks for me ok. So why i can't send it with storescu? Somehow the pixeldata is 1 byte shorter as required. I read this files also with some DICOM viewers. All viewers opened the file without any problem.

repairing of the DICOM file is not a option for me, because i implement an archive and i can't modify contents...

#9 Post by **Jörg Riesmeier** » Mon, 2011-03-28, 14:09

Parsing looks for me ok. So why i can't send it with storescu? Somehow the pixeldata is 1 byte shorter as required.

Thank you for the sample file. I checked it with storescu/scp from DCMTK and can confirm that it does not work as expected. Using storescu from DCMTK 3.5.4 and storescp from DCMTK 3.6.0, it works!

That means: Changes between both releases led to the observed behavior. My first guess would be the following (from ANNOUNCE.360 file):

The write methods in dcmdata now handle large raw data elements without loading everything into memory. This allows very large images to be sent over a network connection or to be copied without ever being fully in memory.

We will have a closer look to it and fix this issue as soon as we've time for it ...

Uli Schlachter · #10 Post by **Uli Schlachter** » Tue, 2011-03-29, 12:04

Hi,

I can't reproduce your original problem. If I work-around the problem in storescu, no odd-length PDV is received and the transfer finishes successfully. I guess that the existing code works around this problem in dimse.cc, lines 769 to 787.
What do I have to do to see the odd-length PDV?

Now for the problem with storescu:
The image has a PixelData element with an odd length. However, the VR of this element is "OW" which means that it contains entities of size 2.
(As a side note, BitsAllocated is 8 and Columns*Rows is the same as the size of the PixelData, so shouldn't this be OB instead of OW?)
storescu sends this dataset without loading it completely into memory, so DcmElement::getPartialValue() is used for getting a fragment. Eventually, the last fragment will be requested (offset + numBytes == the length of the element). However, because this element has VR OW, getPartialValue() tries to load one byte beyond the end of the value (needed for switching to the right endianness) and thus hits the end of the input stream. This is where the "invalid stream" error is generated (dcelem.cc, line 1512).

I don't yet have any idea how getPartialValue() should work-around this problem, because inventing 0-bytes for an element with VR FL or FD sounds like a bad idea.
Currently, I just check for valueWidth == 2 and the end of the input stream and then invent a zero byte which just fixes the problem for this file.

Uli

xcoder · #11 Post by **xcoder** » Tue, 2011-03-29, 12:20

well, maybe this was not correct reported by me. i reported this, because it was a workaround for the last years in our codebase of dcmtk. but maybe the problem was somewhere else and this is already fixed.

so after i tried it, i got the new issue with this file.

Uli Schlachter · #12 Post by **Uli Schlachter** » Fri, 2011-04-01, 09:59

The problem with DcmElement::getPartialValue() has been fixed in git:
http://git.dcmtk.org/web?p=dcmtk.git;a= ... 7d60baed10

The next snapshot will contain this fix.

Thanks for the report and hopefully this solves al your problems with the sample file.

xcoder · #13 Post by **xcoder** » Fri, 2011-04-01, 19:56

Thanks for your great and fast support.

Glenn

DICOM @ OFFIS

DIMSE: Odd Fragment Length

DIMSE: Odd Fragment Length

Who is online