Fast Dicom load

[gzhang]

Hi,
DcmFileFormat::loadFile() seems to be a common way in loading Dicom files from disk. I wonder where might be the bound of speed for this method: reading or parsing or? Would stdio::fread() + DcmInputBufferStream::setBuffer() + DcmFileFormat::read(DcmInputBufferStream &) be faster? Suppose in some cases we have prior knowledge that the parsing is most likely to be successful, would there be a faster way?
Thanks!

[J. Riesmeier]

Without knowing any details on the background of your question, I think there is no (real) answer to it.

[Jan Schlamelcher]

You can use perf on linux and dtrace on OS X to measure such detailed timings. My guess would be that it is disk IO bound, probably a close race when using a fast SSD. You could try copying a file to a tempfs location and compare loadFile() performance.

[gzhang]

Hi, sorry for the vagueness earlier..
I have a series of single-framed Dicom files to load and display. What I usually did was loading them in a loop:
DcmFileFormat ** fileFormats = new DcmFileFormat * [N];
for(int n = 0; n < N; n++) {
fileFormats[n] = new DcmFileFormat;
fileFormats[n]->loadFile(filePath);
}
In most cases, I knew in advance that the files exist and are in correct format, so the loading was always going to be successful. Then I have 2 questions:
1) If I do not create any "DicomImage" object in the loop, the files are not going to be read into the RAM, but only read in later at the time when I am about to show the image, which is rather slow if I scroll across the series.
2) If I do create the "DicomImage" objects in the loop, like preparing them in advance, they are all read into the RAM within the loop and the scrolling becomes fluent, but this loading loop becomes rather slow.
So, I wonder how to get an optimal trade-off? Is there a faster way to force loading? Apart from disk limitations.

[Jan Schlamelcher]

How about putting the load loop in a different thread and only wait for an image to finnish loading when it is finally needed?

[gzhang]

yes, the loop is always put in a separate thread. If I understand right, waiting for only one image load when it is finally needed is like scenario (1), which becomes slow when I start to scroll among images. Probably the ideal would be "load when it is idle" instead of "load when it is finally needed", or may it be too "ideal"

[J. Riesmeier]

In most cases, I knew in advance that the files exist and are in correct format, so the loading was always going to be successful.

In order to make sure that the file actually is in DICOM format and contains a particular Storage SOP Class, you could also load the file meta information header first: see this Howto.

If I do not create any "DicomImage" object in the loop, the files are not going to be read into the RAM, [...]

Of course, the DICOM dataset is read from file when calling DcmFileFormat::loadFile(). Only large element values (by default, > 4 Kbytes) like e.g. Pixel Data are only loaded on demand, i.e. when they are accessed.