DIMSE: Odd Fragment Length
Moderator: Moderator Team
DIMSE: Odd Fragment Length
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
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
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
-
- DCMTK Developer
- Posts: 2049
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
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:
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.
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.) */
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.
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)
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)
-
- DCMTK Developer
- Posts: 2049
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Hi,
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
Well, that seems to have nothing to do with your code line in dimse.cc, right?W: DcmItem: Length of element (7fe0,0010) is odd
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
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...
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...
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
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!Parsing looks for me ok. So why i can't send it with storescu? Somehow the pixeldata is 1 byte shorter as required.
That means: Changes between both releases led to the observed behavior. My first guess would be the following (from ANNOUNCE.360 file):
We will have a closer look to it and fix this issue as soon as we've time for it ...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.
-
- DCMTK Developer
- Posts: 120
- Joined: Thu, 2009-11-26, 08:15
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
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
-
- DCMTK Developer
- Posts: 120
- Joined: Thu, 2009-11-26, 08:15
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.
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.
Who is online
Users browsing this forum: Baidu [Spider] and 1 guest