Default SOP Class UID, when writting images

[Mathieu Malaterre]

Hello,

I am further integrating gdcm(*) into ITK(**) and I am not sure how to
continue. So far I was reading in a DICOM image, then user could
register, segment, apply gaussian blur etc... And save it back as DICOM
file. The DICOM dictionary was carried along the image process and then
pass it the writer.

The problem is then: Can we still consider the modified image of
Modality CT -for example- since it has been modified ? Furthermore now I
authorized people to load in RAW data and save it as DICOM. The question
is then: what default SOP Class UID (0008,0016) can I use if he/she
doesn't provide one ? And again if the image has been modified can this
be considered of any Modality ?

Thanks for any help
Mathieu

(*) http://www.creatis.insa-lyon.fr/Public/Gdcm/
(**) http://itk.org/

So far my default is:
0008|0016[UI] [SOP Class UID] [1.2.840.10008.5.1.4.1.1.2 ] ==>
[CT Image Storage]

[eric.g...@gmail.com]

Your title "Default SOP Class" and question in 2nd paragraph "Can we
still consider modified image Modality CT...?" aren't really the same
issue.

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