DICOM @ OFFIS

Sorry for the slow reply but I have been really busy with other stuff and on holiday. What we notice in our own program is that it can take a few seconds to load a multiframe DICOM file (so just loadFile(...)). I don't know the effect of disk caching and symlinks but I do know that Windows disk cach...

Thanks for taking a look at the code so quickly. I didn't add the stopParsingAtElement parameter to loadFile() since we don't use that at the moment (we use wchar_t* filenames) and I figured it could easily be added if needed. ;) I agree that a StopParsingAtElement and StopParsingAfterElement functi...

Would you be willing to take a look at our implementation and tell us what you think if I sent you the code ? Sure :-) But why don't you just specify the tag of the last data element you are interested in? The problem is that not all tags that we are interested in are always present in a DICOM file.

Thank you for the quick response. I should probably have been a bit more specific as to our problem in my initial post. When scanning for DICOM files of a specific modality or vendor we notice that multi-frame files where the PixelData is stored as PixelSequence can take significantly longer to load...

At the moment it is already possible in DCMTK to stop parsing tags once a certain tag is found specified by dcmStopParsingAfterElement. The current functionality depends on the dcmStopParsingAfterElement tag to be present otherwise the whole file is still parsed (including the DCM_PixelData) which s...

No, our problematic RLE encoded files were IVUS images from Jomed/Endosonics, and files from some years ago.

Most modern IVUS DICOM files seem to use (lossless) JPEG instead of RLE.

We are encountering problems reading DICOM files on Japanese Windows systems. The filenames can contain unicode (Kanji) characters but the DcmFileFormat::loadFile(...) function and DcmInputFileStream constructor only support const char *. On Windows system unicode is implemented as UTF-16 instead of...

Sorry to trouble you again but I've encountered another DICOM file that DcmTk has trouble reading. In this instance it's a multi-frame JPEG encoded file with an odd number of pixels per frame (in my case 271 x 379). In the getUncompressedFrame(...) function in dcpixel.cc there is a check on an odd n...

Thank you for the quick response. The patch does indeed seem to do the trick.

I have now managed to change an existing dicom file which I can sent you.

It gives the same behavior (works with dcm2pnm 3.5.4 but not 3.5.5-26-feb snapshot)


Where should I sent it ?

Thank you for your replies so far. the snapshot version of dcm2pnm also crashes: Application Error The Exception unknown software exceptioon 0xc00000005 occured in the application at location 0x7d21157. The 3.5.4 version I downloaded from the dcmtk website doesn't crash. The image seems to be uncomp...

I have a DICOM image with the following properaties: PhotometricInterpretation = PALETTE COLOR NumberOfFrames = 99 Rows = 502 Columns = 502 BitsAllocated = 8 BitsStored = 8 HighBit = 7 PixelRepresentation = 0 PixelData type is OW When I try to read this image using DicomImage::createWindowsDIB(...) ...

For the last few years we've used a snapshot version of DCMTK 3.5.4 in which we "patched" the RLE decoder so that we could correctly read the incorrectly RLE encoded DICOM files. Recently we have been looking at the latest 3.5.5 snapshots of DCMTK because of the ability to decode only a li...