Default SOP Class UID, when writting images - DICOM

This is a discussion on Default SOP Class UID, when writting images - DICOM ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Default SOP Class UID, when writting images

  1. Default SOP Class UID, when writting images

    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]

  2. Re: Default SOP Class UID, when writting images

    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.


+ Reply to Thread