why does DcmFileFormat::loadFile perform differently in Vista and XP?

Message

richardander · #1 Post by **richardander** » Thu, 2011-03-17, 10:30

Hello,

I am using the following code to open a multiframe DICOM image.


DcmFileFormat fileformat;
OFCondition status = fileformat.loadFile(filename);

if (status.good())
{
...
}

In windows Vista, this program works fine and status.good() is true;

However, when the program runs in Windows XP, the status.good() is false.

Obviously, the loadFile() of DcmFileFormat performs differently in Windows Xp and Vista.

BTW, the development is VS2008 in Vista and the exe program is compiled in Vista.

Could anyone help solving this problem?

Thank you!

#2 Post by **Jörg Riesmeier** » Thu, 2011-03-17, 16:10

Are there any other differences in the environment, e.g. environment variables that are used by DCMTK set or unset? Memory exhausted ...

What exactly is the returned condition and what is the output in verbose/debug mode?

richardander · #3 Post by **richardander** » Thu, 2011-03-17, 17:38

I did not set any any environment variables in the client machine (Windows XP). In the development machine (window Vista), I did not set anything special. All I did was install DCMTK and compiled the library.

Please let me know if any any environment variables should be set.

Memory is not an issue. the same problem consistantly happens after rebooting the computer.

In the development machine (Vista), everything is ok in both release and debug mode. Is there any other way to find out the error message in loadFile() function?

thank you!

#4 Post by **Jörg Riesmeier** » Fri, 2011-03-18, 08:55

So, I can only repeat: What is the returned condition, e.g. "status.text()"?

Btw, are you using DCMTK 3.5.4 or 3.6.0 - I'm asking because the logging changed completely between these versions.

richardander · #5 Post by **richardander** » Fri, 2011-03-18, 10:19

The status.text() is "Invalid stream".

I am using 3.5.4.

Please let me know what to do.

BTW, when I load single frame DICOM images in client PC, this function works OK.

Thank you.

#6 Post by **Jörg Riesmeier** » Fri, 2011-03-18, 10:30

Does the standard DCMTK tool dcmdump (compiled on the Vista machine) work on this DICOM file (on the XP machine)?

richardander · #7 Post by **richardander** » Fri, 2011-03-18, 18:21

The same version of dcmdump.exe ran on XP and Vista on the same dicom image file.

commandline: dcmdump -d im_0019.dcm

It worked on vista. However, In XP, here is the output:

Code: Select all

DcmItem: Non-standard VR '!!' encountered while parsing attribute (001c,0026), assuming 2 byte length field
DcmItem: Dataset not in ascending tag order, at element (001c,0026)
DcmItem: Non-standard VR '0' encountered while parsing attribute (001c,000f), assuming 2 byte length field
DcmItem: Dataset not in ascending tag order, at element (001c,000f)
DcmItem: Non-standard VR 'C' encountered while parsing attribute (0027,0033), assuming 2 byte length field
DcmItem: Length of attribute (0027,0033) is odd
DcmItem: Dataset not in ascending tag order, at element (0027,0033)
DcmItem: Non-standard VR '' encountered while parsing attribute (1c00,0f00), assuming 2 byte length field
DcmElement: Unknown Tag & Data(1c00,0f00) larger (16384) that remaining bytes in file
DcmItem: Dataset not in ascending tag order, at element (1c00,0f00)
dcmdump: error: Invalid Stream: reading file: im_0019

In Vista output, I quote some below. (001c,0026), (001c,000f), (0027,0033), (1c00,0f00) are not found. I can send the full output to you. If needed, I can email you the image file.

Your help is greatly appreciated!

Code: Select all

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: LittleEndianExplicit
(0002,0000) UL 200                                      #   4, 1 MetaElementGroupLength
(0002,0001) OB 00\01                                    #   2, 1 FileMetaInformationVersion
(0002,0002) UI =EnhancedMRImageStorage                  #  28, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.3.46.670589.11.17296.5.20.1.1.6372.2008041509501456200] #  56, 1 MediaStorageSOPInstanceUID

...

#8 Post by **Jörg Riesmeier** » Mon, 2011-03-21, 09:43

It seems that the DCMTK dataset parser chokes on this DICOM file. Have you also tested the "official" Windows binaries from the DCMTK web site?

richardander · #9 Post by **richardander** » Tue, 2011-03-22, 18:44

Yes. I download the windows 32bit binary file, dcmtk-3.6.0-win32-i386.zip
40,017K DCMTK 3.6.0 for Windows (32 bit) , from your website : http://dicom.offis.de/dcmtk.php.en

running it in windows XP with commandline: dcmdump -d im_0019

Here is the output :

Code: Select all


D: $dcmtk: dcmdump v3.6.0 2011-01-06 $
D: 
D: DcmItem::checkTransferSyntax() TransferSyntax="Little Endian Explicit"
W: DcmItem: Non-standard VR '  ' (13\00) encountered while parsing element (001c,0026), assuming 2 byte length field
W: DcmItem: Dataset not in ascending tag order, at element (001c,0026)
W: DcmItem: Non-standard VR '0 ' (30\00) encountered while parsing element (001c,000f), assuming 2 byte length field
W: DcmItem: Dataset not in ascending tag order, at element (001c,000f)
W: DcmItem: Non-standard VR 'C ' (43\00) encountered while parsing element (0027,0033), assuming 2 byte length field
W: DcmItem: Length of element (0027,0033) is odd
W: DcmItem: Dataset not in ascending tag order, at element (0027,0033)
W: DcmItem: Non-standard VR ' 3' (00\33) encountered while parsing element (1c00,0f00), assuming 2 byte length field
E: DcmElement: Unknown Tag & Data (1c00,0f00) larger (16384) than remaining bytes in file
W: DcmItem: Dataset not in ascending tag order, at element (1c00,0f00)
E: dcmdump: I/O suspension or premature end of stream: reading file: im_0019

Do you need image to figure out the problem?

Thank you!

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

Yes, it would certainly help to get the sample file that demonstrates this strange behavior.

richardander · #11 Post by **richardander** » Tue, 2011-03-22, 22:30

Please let me know how to send the file to you.

Thank you!

#12 Post by **Jörg Riesmeier** » Tue, 2011-03-22, 22:48

I thought that the email address is well-known: dicom/at/offis/dot/de.

richardander · #13 Post by **richardander** » Tue, 2011-03-22, 23:51

Sorry for my ignorance...

The image file should be in your mailbox now.

Thanks again for the help!

#14 Post by **Jörg Riesmeier** » Wed, 2011-03-23, 09:45

Thank you for the file. I don't know why different versions of the Windows OS should behave differently, but the file you've sent us seems to be corrupted: There is some "garbage" data after the PixelData element. So when you use dcmdump from DCMTK 3.6.0, option "--stop-after-elem PixelData" or "--ignore-errors" should work ...

Per · #15 Post by **Per** » Wed, 2011-03-23, 10:15

I find the error message intriguing, though. Why would it assume that 'C ' has a 2-byte sized length field? The standard says that all new VRs will have 4 byte sized length fields. I have tested earlier that dcmdump recognizes new VRs correctly as 4-byte size, so is there some intelligent heuristic that it uses to guess the size of the length field of unknown VRs?

DICOM @ OFFIS

why does DcmFileFormat::loadFile perform differently in Vista and XP?

why does DcmFileFormat::loadFile perform differently in Vista and XP?

Who is online