file offset of pixel data

[csmeso]

I have to read large uncompressed image sequences (>100MB). It is possible to get the pixel data with

Code: Select all

Uint8 *pixelData=NULL;
result=dpix->getUint8Array(pixelData);

But this takes a lot of memory. I want to get the pixel data frame by frame. The idea is to get the file offset of the pixel data and then read it frame by frame. I found that after performing

Code: Select all

dataset->findAndGetElement(DCM_PixelData, delem)

the member delem->fLoadValue.offset_ contains exactly the offset I need - but I didn't found any "legal" way to access this value. Is there any way?

Thanks,
Christian

[Marco Eichelberg]

No. There is no legal way to access DcmElement::fLoadValue.offset_ (and this private element is actually not guaranteed to exist - once you have called something like DcmElement::getUint8Array or some other member function that causes DcmElement to load the value to memory, fLoadValue is set to NULL). There is also no API call that would allow you to retrieve the pixel data frame by frame. This is a much-requested feature but does not exist at the moment. Instead of providing access to the offset within the file, a clean solution would offer an API method such as DcmElement::copyUint8Array(Uint8 *pixelData, Uint32 numBytes, Uint32 offset) to copy a given number of bytes into a buffer that would be allocated by the caller. Offset would be the offset within the pixel data array. This method should then load the data directly from file without allocating a big buffer internally. The problem with this approach, which sounds simple in the first place, is byte ordering. You also have to provide copyUint16Array, copyUint32Array etc. methods that correct the byte ordering, which might be different in the file than in memory. This is possible but not entirely trivial because you might have to read some extra bytes before the start offset and after the end offset to have all information available that is needed for correct byte-swapping, and you would also have to decide what happens if an access is not allocated with the structure size, which would be entirely possible if the network transmission code would be migrated to also use these functions.

[csmeso]

Thank you for that - not very helpful - reply. In the meantime, I played a little with DicomImage class.
Another idea for comfortable access to such image sequences would be if you wouldn't load the entire image sequence in the constructor of DicomImage, but load only the requested images when calling e.g. createWindowsDIB.

Just an idea for the next release...

[Marco Eichelberg]

Thanks for the suggestion, we have thought about that as well. When the toolkit was originally developed, one of the design choices was that one dataset (one file) will always fit into main memory - and this was not an issue until recently. The problem is that a modification of the toolkit to only load data as needed requires changes in many places:

• dcmdata - provide an API for partial access to attribute values without loading the complete attribute value into main memory. Also provide API for storing large attribute values in a temporary file while receiving over network
• dcmnet - change sending code to only access partial attribute values (i.e. as much as fits into a single PDV). Change receiving code to store large attributes in temporary files.
• DcmCodec classes (RLE, JPEG and our private JPEG 2000 extension) - change API to allow for de-compression of individual frames instead of complete multiframe object. Also change code to use partical access API.
• dcmimage/dcmimgle: Change constructor code to only access those frames of an image that are needed. Add explicit calls to decompression codec to only decompress pixel data when actually needed.

All of that is entirely possible, but plenty of work, which means: I'm looking for a volunteer here