How to speed up writing of DICOM files?

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
bruce
Posts: 7
Joined: Thu, 2006-04-06, 18:55

How to speed up writing of DICOM files?

#1 Post by bruce » Wed, 2006-05-24, 22:15

We have a device that acquires images at 14 frames per second. When saving of images is on, the frame rate drops to 11 fps. Each image is saved in one DICOM file. What can I do to speed up the saving of files? There are reasons not to save multiple images in one file.

I'm using dcmtk 3.5.4. My file saving function consists of 40 putAndInsert calls, followed by:
chooseRepresentation();
canWriteXfer();
saveFile();

One method I've used elsewhere is to call setbuf() on the output stream to provide a buffer that is larger than the file being written. Is there any way of doing this with dcmtk?

Mike Hale
Posts: 2
Joined: Wed, 2005-05-18, 11:22
Location: Halifax, NS, Canada

#2 Post by Mike Hale » Sun, 2006-05-28, 16:34

You don't mention the resolution of the images or the number of images that would be collected in a single series, so my ideas may or may not be useful.

I would consider simply retaining the images in memory until acquisition is complete, and then writing them to disk when time is less critical.

An alternative might be to write the image data to disk in "real time", using a representation of your own choosing. Once the acquisition is finished, you could then re-read the images from the (temporary) storage and then create the DICOM files that you require.

bruce
Posts: 7
Joined: Thu, 2006-04-06, 18:55

#3 Post by bruce » Tue, 2006-05-30, 22:02

Images are about 350x450. The user controls recording so that the recording time is not known. This is an ultrasound device so the user positions the transducer then starts recording. Typically 5-10 seconds are recorded, then the user changes the angle and records again. Sometimes users want to record minutes worth of images. Worse case, it looks like I would have to store about 500 MB in memory.

We had a proprietary format for saving images. I decided to get rid of that and use DICOM as the primary file format. In terms of speed, DICOM is better than the earlier format. I was losing 5 fps with the proprietary format and lose 3 fps with DICOM. I'm being pushed to reduce that even further!

I was hoping there would be a method that would allow me to set a larger buffer for I/O. I could always modify dcmtk, but this would cause a maintenance problem.

Mike Hale
Posts: 2
Joined: Wed, 2005-05-18, 11:22
Location: Halifax, NS, Canada

#4 Post by Mike Hale » Wed, 2006-05-31, 10:31

Hi Bruce,

You mentioned in your original post that you wanted or needed to keep the images in separate files. Would it be possible, though, to store the live stream in a single file (accompanied by relevant marker information for each frame) and then post-process this file to generate the DICOM data set?

This approach might reduce the operating system overhead associated with the creation of new directory entries for each file (for example) and allow a faster transfer rate to the disk.

I agree that modification of the dcmtk source has the potential to create a maintenance problem for you.

Good luck!

Michael Onken
DCMTK Developer
Posts: 1830
Joined: Fri, 2004-11-05, 13:47
Location: Oldenburg, Germany
Contact:

#5 Post by Michael Onken » Wed, 2006-05-31, 15:13

Hi Bruce,

I'm not able to give you a DCMTK-solution for your problem. However, you could try to write the image data as raw data to disk, because I would think, that inserting those tags is relatively time consuming in your scenario. Later, at a time when no images are acquired, you could do the "DICOMizing" of your raw data. Maybe you could also transfer the raw data to another system via network, that does the DICOM stuff for you.

Maintenance: If you would extend DCMTK regarding some (portable) buffer routines and these are functions, that could be interesting for other users as well, there is a good chance, that "your" code could be integrated into the next release (if you like to share..). Then maintenance woul d not be the problem :)

Regards,
Michael

bruce
Posts: 7
Joined: Thu, 2006-04-06, 18:55

#6 Post by bruce » Sat, 2006-06-03, 00:00

Thanks for the suggestions. I think I'll hack the changes to dcmtk and see how much improvement there is. If there's enough speed-up, then I'll write a "release" version that adds a method for allowing the user to supply their own buffer (I'm not sure how at the moment, I can see two different approaches with the dcmtk class hierarchy). Then I'll submit it to OFFIS and they can decide if they want to add it to a release.

If there isn't enough improvement, then I'll try your suggestion of writing a single file with all images and "DICOMizing" when recording is stopped.

Colby Dillion
Posts: 13
Joined: Tue, 2005-06-28, 16:48

#7 Post by Colby Dillion » Sat, 2006-06-03, 16:17

We were recording echocardiograms not long ago and ran into the same issue. Post processing was tried but it was too difficult to explain why the techs had to wait, sometimes 2 or 3 minutes, after each study.

Our solution was to write a dicom file with known unique values for the elements we needed to change and store that in memory. We found the offsets to those known unique values and then we would overwrite the values in memory and write that to disk. This got rid of the DCMTK overhead. I will be honest that this solution was only maybe 20-25% faster but it did make enough difference that we could store the images as they were being recorded. It did require us to get a slightly expensive capture card with a direct api (foresight imaging) to get rid of VFW overhead and we were using 10k rpm SATA drives.

I forgot to mention that we were capturing a slightly larget resolution than Bruce. The Docs wouldn't read the smaller image since it was being scaled and resulted in a very graining/blobby image.

Colby

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1301
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#8 Post by Marco Eichelberg » Sun, 2006-06-04, 20:05

To come back to the initial suggestion of using setbuf() with a very large buffer size: this is possible in a portable way in DCMTK. Instead of using DcmFileFormat::saveFile(), you would have to duplicate the content of this method (defined in dcmdata/libsrc/dcfilefo.cc) in your own code - this is a short static method of about 20 lines of code, should be no big deal. Instead of declaring an object "DcmOutputFileStream fileStream" with the filename as parameter to the constructor, you can pass a FILE* instead. This means: Create you own FILE* with fopen, call setbuf on the FILE* structure and then pass the open file to the DcmOutputFileStream constructor. I cannot say how much performance you will gain, but the attempt might be worthwhile. Another option might be the use of mmap()-based file I/O, which would, however, require a re-implementation of class DcmFileConsumer.

Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 1 guest