[Dcmlib] Overlay in DICOM images - follow up

[Emmanuel Olart]

Jean-Pierre Roux wrote:

> Emmanuel Olart wrote:
>
>> Hi all,
>>
>> Following our questions last week on overlays in DICOM images, I 
>> received this morning my first image with an overlay in the DICOM 
>> header.
>> This overlay is a binary mask which is supposed to be a lesion contour.
>>
>> Here is what I can see using PrinFile:
>>
>> As it has been guessed last week, this is a secondary capture image :
>>
>> V 0008|0008[CS] [Image Type] [DERIVED\SECONDARY\MPR\CSA 
>> MPR\\CSAPARALLEL\M\ND\NORM]
>> S 0008|1140[SQ] [Referenced Image Sequence]
>>   |  --- SQItem number 0
>>   | V fffe|e000[UL] [Item]
>>   | V 0008|1150[UI] [Referenced SOP Class UID] 
>> [1.2.840.10008.5.1.4.1.1.4 ]  ==>       [MR Image Storage]
>>   | V 0008|1155[UI] [Referenced SOP Instance UID] 
>> [1.3.12.2.1107.5.2.30.25641.30000005113007072225000001677]
>>
>> An icon is included in the header, I don't know if we have yet a 
>> simple way to view it ?
>
>
> We have *not*!
> :-(
> You may also get icons in a DicomDir (at IMAGE level, or at SERIE level)
> No simple way to get the image from an icon.
> (you need to get the LUT, also;
> Ans sometimes, the icon is *compressed* (not a joke!)
> Even for the *image* BuildLUT was moved to PixelReadConvert, therefore 
> it's not available for end user.
> It's time for us to have a new architecture for gdcm !
>
OK well this doesn' t matter at the moment, no need to read this right now.

>> S 0088|0200[SQ] [Icon Image Sequence]
>>   |  --- SQItem number 0
>>   | V fffe|e000[UL] [Item]
>>   | V 0028|0002[US] [Samples per Pixel] [1] x(1)
>>   | V 0028|0004[CS] [Photometric Interpretation] [PALETTE COLOR ]
>>   | V 0028|0010[US] [Rows] [64] x(40)
>>   | V 0028|0011[US] [Columns] [64] x(40)
>>   | V 0028|0100[US] [Bits Allocated] [8] x(8)
>>   | V 0028|0101[US] [Bits Stored] [8] x(8)
>>   | V 0028|0102[US] [High Bit] [7] x(7)
>>   | V 0028|0103[US] [Pixel Representation] [0] x(0)
>>   | V 0028|1101[US] [Red Palette Color Lookup Table Descriptor] 
>> [256\0\8] x(100)
>>   | V 0028|1102[US] [Green Palette Color Lookup Table Descriptor] 
>> [256\0\8] x(100)
>>   | V 0028|1103[US] [Blue Palette Color Lookup Table Descriptor] 
>> [256\0\8] x(100)
>>   | B 0028|1201[OW] [Red Palette Color Lookup Table Data] 
>> [gdcm::Binary data loaded; length = 256]
>>   | B 0028|1202[OW] [Green Palette Color Lookup Table Data] 
>> [gdcm::Binary data loaded; length = 256]
>>   | B 0028|1203[OW] [Blue Palette Color Lookup Table Data] 
>> [gdcm::Binary data loaded; length = 256]
>>   | B 7fe0|0010[OW] [Pixel Data] [gdcm::NotLoaded Ad.:8894 x(22be) 
>> Lgt:4096 x(1000)]
>>
>> And last : here is all informations for the overlay image :
>>
>> V 6000|0010[US] [Rows] [484] x(1e4)
>> V 6000|0011[US] [Columns] [484] x(1e4)
>> V 6000|0015[IS] [Number of Frames in Overlay] [1 ]
>> V 6000|0022[LO] [Overlay Description] [Siemens MedCom Object Graphics]
>> V 6000|0040[CS] [Overlay Type] [G ]
>> V 6000|0050[SS] [Overlay Origin] [1\1] x(1)
>> V 6000|0051[US] [Image Frame Origin] [1] x(1)
>> V 6000|0100[US] [Overlay Bits Allocated] [1] x(1)
>> V 6000|0102[US] [Overlay Bit Position] [0] x(0)
>> B 6000|3000[OW] [Overlay Data] [gdcm::NotLoaded Ad.:13122 x(3342) 
>> Lgt:29282 x(7262)]
>>
>> As we can see, this is a binary mask, size is 484x484 (same as the 
>> original image).
>> Bits allocated = 1 : i.e. one byte is used to store information 
>> concerning EIGHT voxels.
>
>
> --> I don't get what you mean ...
> (Any image sample is welcome)
> JPRx
>
Quite simple :
You can see that the data lenght is 29282 , this is 484 * 484 / 8.
This is a binary mask, values may be only 1 or 0, so they don't waste 
any place, they just use all bits to encode their mask.

If I want to display such an image I need to divide a single byte into 
eight char (it would be in this case a char* of size 484*484)


>> Finally the original image data is contained in this file :
>>
>> B 7fe0|0010[OW] [Pixel Data] [gdcm::NotLoaded Ad.:42416 x(a5b0) 
>> Lgt:468512 x(72620)]
>>
>> If I read this image with gdcm, I of course get only the original 
>> image data. I'd like to get also the overlay data, maybe in a 
>> separate ImageData (used later to superpose overlay on image).
>>
>> It's quite easy for me to code something to get the value of the 
>> 0x6000, 0x3000 field and to convert it to a char* for VTK display for 
>> example. I personnaly think that GDCM should provide a way to get 
>> either Icon and Overlay data withj separate methods :
>>
>> gdcm::FileHelper::GetPixelData()
>> gdcm::FileHelper::GetIconData()
>> gdcm::FileHelper::GetOverlayData()
>>
>> What do you think ?
>>
>> Manu
>>
>> PS: I'll anonymize one of these images if you want to have a look at it.
>>
>


-- 
Emmanuel OLART, IT Manager
*THERALYS*
Diagnostic & Therapeutic Image Analysis in Clinical Trials

Address : Bioparc, 60 av. Rockefeller, 69008 Lyon, France
+33 (0)4 26 23 05 05 (Phone)
+33 (0)4 26 23 05 06 (Fax)
Email : eolart at theralys.com <mailto:eolart at theralys.com>
THERALYS <http://www.theralys.com/>