[Dcmlib] [Fwd: Re: Default SOP Class UID, when writting images]

[Jean-Pierre ROUX]

>J'ai pose la question qui tue au gourou DICOM. Et voila une reponse. 
>Mon probleme c'etait est-ce qu'une image segmentee/filtree/ ou autre 
>est toujours une image CT...
>
>---------------------------------------------------------------------
>Your title "Default SOP Class" and question in 2nd paragraph "Can we
>still consider modified image Modality CT...?" aren't really the same
>issue.


OK ...
The global conclusion is :
- we (as the Write service provider) *never* modify (0008,0060),Modality
- the user should never modify it (and we have no way to check 
whether he did or not)
- It's up to the user to decide if a modified image still belongs to 
the original SOPClass -for instance : he grapped a sub-image and 
writes it as a new Dicom Image, to save room on disc (?!)- or not 
-for instance : he segmented the image, or turned it into 'false 
color', etc-, in the last case the new SOPClass UID if 'Secondary 
Capture'.
If the user didn't initialize SOPClass we default it to 'Secondary Capture'
If the user didn't initialize (0008,0060),Modality, we default it to 
'OT' (other)

I've got a question about 0008,0008 :
Native images are quoted as 'ORIGINAL\PRIMARY
An other frequently seen value is 'DERIVED\SECONDARY'
Entry 0008,0008 has a VM = '1-n', and we can see many different values
(just grep 0008|0008 from the verbose output of Testing/TestPrintAllFiles)
I didn't manage to guess the meaning.
Could you ask your favorite Dicom guru ?

>
>A modified (for example segmented) CT image is no longer a CT SOP class
>- the pixel/voxel data is no longer hounsfield units but instead
>contains some coded data corresponding to the tissue classification
>you've assigned. But it can still be labeled with the  modality code
>(0008,0060)=CT. You see this fairly often on CT and MR consoles where
>they support processing images of one or more series in order to
>generate secondary capture images (MIP images for example). These
>derived images are no longer CT or MR images as defined by the SOP
>class;  yet they still retain the source image modality labeling as a
>CT or MR image.
>
>Secondary Capture seems to the SOP Class choice of last resort when
>storing some derived image in which the sematic content of the original
> image pixels has been changed. A secondary capture multiframe
>greyscale byte, greyscale word, or true color object SOP Class would be
>a possiblity for your cross-sectional imaging derived object SOP class.
>The secondary capture MF sop classes have the disadvantage of not
>including the frame of reference module in the IOD definition whereas
>the source images do  include the frame of reference data.

Frame of Reference UID : within a given 'spacial' serie, it's the SOP 
Instance UID of one of the images.
Benoit's option to insert this entry, and force it with a value of 
it's own wasn't a very rich idea :-(
I'll comment it out.
I'll push out 'Frame of Reference UID' if 'Frame Numbers' entry 
exists, to ensure Dicomp consistency.

JPRx

>Presumably
>you would want to carry this data forward in your derived object. You
>could  do that by putting the spatial data into the Secondary Capture
>MF objects anyway (producing a standard extended secondary capture
>multiframe object);  but receivers of the object wouldn't neccessarily
>know look for and utilize that data in the object.
>---------------------------------------------------------------------
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib

   Jean-Pierre ROUX
   UMR CNRS 5515-CREATIS
   Laboratoire de Radiologie Experimentale
   Hopital Cardiologique
   28 Avenue du Doyen LEPINE
   B.P. Lyon-Montchat
   69394 Lyon Cedex 03
 
   Tel      : (+33) 04 72 35 74 12
   Fax      : (+33) 04 72 68 49 16
   URL      : http://www.creatis.univ-lyon1.fr
   e-mail   : jpr at creatis.univ-lyon1.fr