Large Multi-frame images

All other questions regarding DCMTK

Moderator: Moderator Team

Message
Author
Alexander Fedotov
Posts: 53
Joined: Thu, 2005-04-14, 15:07
Location: St. Petersburg, Russia

Large Multi-frame images

#1 Post by Alexander Fedotov »

I have got a big problem with multi-frame images.
If do like so:
m_pDCMTKImage = new DicomImage(pDataset, EXS_Unknown/*EXS_LittleEndianExplicit*/,
CIF_MayDetachPixelData, 0, 1);

It loads all frames in the memory and it takes much time.
The number of frame in Angiography may be 1000,
and the size of one frame is 1024*1024*16 bit.

Is possible to load only one frame of the image?

Thanks in advance,
Regards,
Alexander.

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

#2 Post by Marco Eichelberg »

There is currently no way to prevent the underlying dcmdata library from loading the complete PixelData attribute and, if compressed, from compressing all frames. This happens on a lower layer, before the DicomImage instance is actually created, and there is no way to bypass that, unfortunately. But then, memory has become cheap :wink:

Alexander Fedotov
Posts: 53
Joined: Thu, 2005-04-14, 15:07
Location: St. Petersburg, Russia

#3 Post by Alexander Fedotov »

[quote="Marco Eichelberg"]There is currently no way to prevent the underlying dcmdata library from loading the complete PixelData attribute and, if compressed, from compressing all frames. [/quote]

Pity. :cry:
Will it be possible in the next DCMTK version?

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

#4 Post by Marco Eichelberg »

I don't think so. This has been on our internal "wish list" for some time (since ca. 1997) and has never had sufficient priority to actually get implemented. I doubt that it will be any different for the next release.

Alexander Fedotov
Posts: 53
Joined: Thu, 2005-04-14, 15:07
Location: St. Petersburg, Russia

#5 Post by Alexander Fedotov »

[quote="Marco Eichelberg"]I don't think so. This has been on our internal "wish list" for some time (since ca. 1997) and has never had sufficient priority to actually get implemented. I doubt that it will be any different for the next release.[/quote]

Three pities for that!
In this case we (and not only we) need another DICOM Toolkit.

Thank you for your reply,
Best regards,
Alexander.

deischi
Posts: 2
Joined: Wed, 2005-11-30, 13:55

What alternative?

#6 Post by deischi »

In this case we (and not only we) need another DICOM Toolkit.
Has someone found a good alternative?

harald

Alexander Fedotov
Posts: 53
Joined: Thu, 2005-04-14, 15:07
Location: St. Petersburg, Russia

Re: What alternative?

#7 Post by Alexander Fedotov »

[quote="deischi"][quote]In this case we (and not only we) need another DICOM Toolkit.[/quote]
Has someone found a good alternative?

harald[/quote]

An alternative for what? For DCMTK?

deischi
Posts: 2
Joined: Wed, 2005-11-30, 13:55

#8 Post by deischi »

Yes - an alternative to DCMTK.

Leadtools would be an option. They can read multi frame dicoms files frame by frame, but are not really cheap.

harald

Alexander Fedotov
Posts: 53
Joined: Thu, 2005-04-14, 15:07
Location: St. Petersburg, Russia

#9 Post by Alexander Fedotov »

[quote="deischi"]Yes - an alternative to DCMTK.

Leadtools would be an option. They can read multi frame dicoms files frame by frame, but are not really cheap.

harald[/quote]

We use LEADTOOLS in our commercial products.
There is a MERGE SDK, but it is not cheap too,
not easy for use, and did not support compression.

jcarnulfo
Posts: 3
Joined: Wed, 2005-04-06, 14:38
Location: France

loading multiframe images one frame at a time

#10 Post by jcarnulfo »

Hi all,

There is a workaround, but it costs a bit of extra coding around DicomImage. Not for the faint at heart...

The idea is this:

The frames are listed in a sequence of items, more precisely a DcmPixelSequence object. That sequence is available in the DcmPixelData object, which you get from the main dataset of the image. The first item in that sequence is a lookup table, which we can ignore (apparently). Then you have one item per frame (DcmPixelItem object), each item containing the compressed bytes of the image.

When instantiating a DicomImage object, it calls the ConvertPixelData method which will find the required Codec and ask it to decompress the frames. The codec is given a pointer on the dataset and one on the sequence of item, with the frames. From the dataset, it will extract the number of frames, plus some image characteristics (frame dmensions, pixel format, etc). From the DcmPixelSequence object, it will extract the frames.

So the trick here, is to play around with the dataset and the DcmPixelSequence object before you instantiate the DicomImage object:

1-set the frame count in the dataset to 1
2-swap the order of the DcmPixelItem objects in the sequence so the one with the frame we want to see becomes first in the list
3-instantiate the DicomImage object
4-restore the framecount and the sequence ordering

Now you have 3 more problems to solve if you want to be able to repeat the same trick on the same dataset, that is without reloading the DICOM file, to display another frame.

First problem: ConvertPixelData will create a new pixel Representation with the uncompressed data, which will be added to the dataset, in the DcmPixelData object. And if you instantiate another DicomImage on the same dataset, it wont decode anything any more. So you will have to remove that new representation at some point using DcmPixelData::removeAllButOriginalRepresentations

Second problem: the Codec will also modify the dataset, because the new pixel representation has a different format. So again, if you instantiate another DicomImage on the same dataset, the decoding will go all wrong. So you need to restore the original values at some point.

Third problem: you cant restore all the things mentionned above right after instantiating the DicomImage, because the other functions of the image will need those values. For example, createWindowsDIB. So basically, the only moment when you should restore everything, is right BEFORE instantiating a new DicomImage for a new frame.

That's about it :-)

I implemented this solution and tried it with various multiframe US images, compressed using JPeg Baseline. It works like a charm. Don't know how it would perform with other Codecs, but theoretically it should work as well.

Please let me know if you try :-)

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

#11 Post by Marco Eichelberg »

The solution you have outlined should work, unless one frame is split into multiple fragments (items in the pixel sequence), something which is explicitly allowed in DICOM. Your algorithm then needs more "intelligence". If you are lucky, you can make use of the offset table (the first item in the pixel sequence) to compute which fragments belong to which frame. If this table is absent, you can really only start decoding the first frame, try to find out how many fragments were used for this (should be possible with a small modification of the DcmCodec class) and then go on with the next frame starting at the next fragment. Or you could try to parse the JPEG bitstream within the fragments and try to locate the next SOI (start of image) marker in the JPEG bistream. Nothing for the faint hearted as well :wink:

hesham
Posts: 8
Joined: Tue, 2005-08-02, 23:17

#12 Post by hesham »

Hi,
jcarnulfo could you please give more infor about how to DcmPixelItem objects in the sequence
I ma new to DCMTK and don't know how to deal with sequences

Jörg Riesmeier
ICSMED DICOM Services
ICSMED DICOM Services
Posts: 2217
Joined: Fri, 2004-10-29, 21:38
Location: Oldenburg, Germany

#13 Post by Jörg Riesmeier »

It might also be worthwhile to have a look at the current snapshot of the DCMTK because there is some experimental code for handling large multi-frame images ...

hesham
Posts: 8
Joined: Tue, 2005-08-02, 23:17

#14 Post by hesham »

could u please tell me what is this experimental code and how can I use it.

Jörg Riesmeier
ICSMED DICOM Services
ICSMED DICOM Services
Posts: 2217
Joined: Fri, 2004-10-29, 21:38
Location: Oldenburg, Germany

#15 Post by Jörg Riesmeier »

The main changes are described in the following entries of the CHANGES.355 file: 2008.05.29, 2007.11.29, 2007.07.11

Post Reply

Who is online

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