Large Multi-frame images

[hesham]

actaully I got the latest version, compiled ok but can't find the changes file u mentioned, latest one is CHANGES.354

[hesham]

sorry, I found it.
I was looking under doc folder

[hesham]

I successfully have uncompressed frame.
what should I do with this frame? How can I use it with DicomImage to get the correct Image?

[tclune]

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...

Marco, let me make sure that you are explicitly talking about JPEG here. I am modifying dcmtk to support frame-at-a-time access and processing as needed. One thing that I did (and worried about at the time) was implement the RLE encoding/decoding for frames in a way that assumes that there is one and only one fragment for each frame. This appears to be explicitly required by 3.5 Annex A, A.4.2.

Your RLE code has a lot more complexity in it, on the assumption that a frame might straddle a fragment. Based on my reading of the DICOM spec, I did not follow your lead on this matter for RLE. My decision was that this code was probably ported from a different compression that allowed such a thing. Am I wrong? Does RLE actually allow multiple-fragment encoding, despite the apparent disavowal in 3.5?

Also, I have seen that JPEG cannot have multiple frames in a fragment, but I have not seen where it explicitly states that multiple fragments are allowed for a frame. Unlike RLE, it does not appear to outlaw them, but I haven't seen the explicit statement that either allows or disallows the practice for JPEG. Could you cite book and page? TIA
________
GIRLFRIENDS PICS
________
List Of Subaru Transmissions Specifications
________
Uhwh Warehouse

[hesham]

Jörg,
I just want to thank you very much about your feedback. I was able to open a multi-frame DICOM file and extracting its compressed frames one by one using he new technique:
1- Open DICOM file to DcmDataset
2- Get DcmPixelData element from the dataset
3- DcmPixelData::getUncompressedFrame(dataset,frameIndex
,fragment,pBuf,frameSize,colormodel);
4- Create a clone of dataset, datasetClone
6- datasetClone->putAndInsertString(DCM_NumberOfFrames,"1");
7- datasetClone->putAndInsertUint8Array(DCM_PixelData
,pBuf,frameSize);
8- dicomImage = new DicomImage(pFrameDataset,
EXS_LittleEndianImplicit,TakeOverExternalDataset);
This works like charm with the application I develop.
But I want to ask couple of questions:
1- Is this pseudo code looks ok, or I am doing something wrong that may raise error in certain conditions?
2- Is this technique is for JPEG compression only, or it is general?

Thanks for ur time

[Jörg Riesmeier]

1 - Looks ok to me, but a little inefficient because you are copying the pixel data first and then overwrite it with the buffer. Please note that DicomImage class is not yet adapted for the new (still experimental) approach.

2 - It is a general approach (for a future release of the toolkit). Please note, however, that currently it has only been implemented for JPEG decompression (see CHANGES files).

[pong]

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 ...

I've extracted the experimental code from the 20090514 snapshot release and backported it to a modified version of 3.5.4 we use, and it seems to work okay for the first few datasets I've thrown at it. I'm wondering about planar configuration, though.

The new getUncompressedFrame() method doesn't tell me the planar configuration of the returned data. I can see in DJCodecDecoder::decodeFrame() that it just uses the value of PlanarConfiguration in the dataset, which is not consistent with DJCodecDecoder::decode() which has more logic to determine the proper planar-configuration. Is this difference intended? If so, I think it should be documented in the header comments.

[Jörg Riesmeier]

I didn't wrote this code but I guess this is because decodeFrame() does not change the DICOM dataset/image (in contrast to decode() which creates a new SOP instance or changes the existing one). Therefore, there is no need to change the Planar Configuration compared to what is stored in the dataset/image.

[paolom]

I didn't wrote this code but I guess this is because decodeFrame() does not change the DICOM dataset/image (in contrast to decode() which creates a new SOP instance or changes the existing one). Therefore, there is no need to change the Planar Configuration compared to what is stored in the dataset/image.

Actually, is it possible to handle large multi-frames images with DicomImage (after using the new DcmPixelData methods)??

[Jörg Riesmeier]

As you can read in the posting above, the DicomImage class is not yet adapted for the new approach - if this was the question. In other words, the DicomImage class still requires the complete content of the pixel sequence to be decompressed (which is done automatically during initialization of this class). Of course, you could delete particular pixel items from the sequence before you feed the dataset into the class ...

[Jörg Riesmeier]

As a follow-up, there is now a "new" approach that can be used to access large multi-frame images based on the DicomImage class, see: http://support.dcmtk.org/wiki/dcmtk/howto/multiframe