DcmElement compact() function

[paolom]

Hi,
I've a CT Dicom File. I use the compact() function and after when I call the getOutpuData() with Windows it fails with a segmentation fault error (test with Mac Os X it works).
This file is inside a CT series images and all the other images work correctly.

I've dump all the series file.
These are the difference tags between this file and all the others:

Code: Select all

(0031,0012) UN 53\49\45\4d\45\4e\53\20\49\53\49\20      #  12, 1 PrivateCreator
(6000,0010) US 512                                      #   2, 1 OverlayRows
(6000,0011) US 512                                      #   2, 1 OverlayColumns
(6000,0040) CS [G]                                      #   2, 1 OverlayType
(6000,0050) SS 1\1                                      #   4, 2 OverlayOrigin
(6000,0100) US 16                                       #   2, 1 OverlayBitsAllocated
(6000,0102) US 12                                       #   2, 1 OverlayBitPosition
(6000,0200) UN e0\7f                                    #   2, 1 ACR_NEMA_OverlayLocation
(6021,0010) UN 53\49\45\4d\45\4e\53\20\43\4d\20\56\41\30\20\20\43\4d\53\20 #  20, 1 PrivateCreator
(6021,1000) UN 43\4d\53\20                              #   4, 1 Unknown Tag & Data
(6021,1010) UN 00\00\81\dc\00\00\00\00\00\00\00\1a\00\00\00\00\00\00\00\00\00\00... # 33244, 1 Unknown Tag & Data

Is it possible that those tags can cause the segmentation fault using the compact() function?

Thanks

P.S. Without using the compact() function also this file works correctly

[J. Riesmeier]

This is just a wild guess: If you are using the DicomImage class on a DICOM image with overlays (group 60xx), you should not delete, compact or make any other significant changes to the DICOM dataset that has been passed to the DicomImage constructor. In your case, the compact() probably removes the pixel data value from memory, in which the overlay bits are also contained.

[paolom]

Ok, but I've another DICOM file with overlay and it works:

Code: Select all

(6000,0010) US 512                                      #   2, 1 OverlayRows
(6000,0011) US 512                                      #   2, 1 OverlayColumns
(6000,0015) IS [1]                                      #   2, 1 NumberOfFramesInOverlay
(6000,0022) LO [Siemens MedCom Object Graphics]         #  30, 1 OverlayDescription
(6000,0040) CS [G]                                      #   2, 1 OverlayType
(6000,0050) SS 1\1                                      #   4, 2 OverlayOrigin
(6000,0051) US 1                                        #   2, 1 ImageFrameOrigin
(6000,0100) US 1                                        #   2, 1 OverlayBitsAllocated
(6000,0102) US 0                                        #   2, 1 OverlayBitPosition
(6000,3000) OW 0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000... # 32768, 1 OverlayData

This dicom has the OverlayData tag....can be this the difference with the previous failed Dicom file?

However, I remember you that on Mac Os X it works..tha error is under Windows

[J. Riesmeier]

The second file obviously uses a separate OverlayData (6000,3000) element.

However, I remember you that on Mac Os X it works..tha error is under Windows

That could be a question of memory management on the particular system ...

[paolom]

Ok, but how can I differentiate when use compact() or no, in the right way?

[J. Riesmeier]

I would strongly recommend to never use compact() on a dataset that has been passed to an still existing DicomImage instance - at least not if the DICOM image contains embedded overlay planes.

[paolom]

You tell me on a previous post:

That means, if the DICOM image has been loaded from file, you could try to use the compact() or compactElements() method from the dcmdata module instead of CIF_MayDetachPixelData. Of course, you should call one of these methods only after DicomImage has processed the dataset. Btw, the latter method requires the current snapshot 3.6.1.

and after this I don't understand your last suggestion:

I would strongly recommend to never use compact() on a dataset that has been passed to an still existing DicomImage instance - at least not if the DICOM image contains embedded overlay planes.

After my test, I've seen that the compact() function doesn't work only for the Dicom images that have the overlaydata inside the pixel data.

So, with your suggest and my test I'm using the compact() function in this mode (and it seems to work correctly):

Code: Select all

DicomImage * TestDicom::allocateDicomImage(int iTuid,DcmDataset *dataSet)
{
    DcmElement * el;
    dataSet->findAndGetElement(DCM_PixelData,el);
    DicomImage *image=NULL;
    switch (iTuid)
    {
        // Implicit VR Little Endian Transfer Syntax: 1.2.840.10008.1.2
            case 1:
                image= new DicomImage(dataSet,
                                      EXS_LittleEndianImplicit,
                                      CIF_KeepYCbCrColorModel);
                break;

        // Explicit VR Little Endian Transfer Syntax: 1.2.840.10008.1.2.1
            case 2:
                image= new DicomImage(dataSet,
                                      EXS_LittleEndianExplicit,
                                      CIF_KeepYCbCrColorModel);
                break;
      }


    if ( image != NULL && el != NULL){
        if ( (image->getOverlayCount() == 0) ||
           ( ( image->getOverlayCount() != 0) && hasOverlayData() ){
                el->compact();
        }
    }

    return image;
}

where the function hasOverlayData() verify the presence of the OverlayData Tag.

Is it a ugly code?

Thanks

[J. Riesmeier]

The reason why you should never delete/compact the pixel data or any other image relevant element value from the DICOM dataset that has been passed to an instance of the DicomImage class is that (by design) this class might access various data elements from the DICOM dataset after the instance has been created. This is especially true for embedded overlay planes, which are part of the Pixel Data element (and which have been retired from the DICOM standard some years ago, by the way). Only the DicomImage class knows for sure when the Pixel Data element is not needed any longer. This is also the reason why there is a CIF_MayDetachPixelData flag ...

I know that this might look strange from today's perspective but at the time when the DicomImage class was initially designed (about 15 years ago), free working memory was limited and, therefore, overlay data and lookup tables were not extracted from the DICOM dataset but only retrieved when needed.