Modifying image data and keeping the data 'correct'. - DICOM

This is a discussion on Modifying image data and keeping the data 'correct'. - DICOM ; Let's say I have some DICOM data with uncompressed image data in it, BitsAllocated = 8, then I modify some of the image data and convert it to 16-bit. What all do I need to update to keep everything "correct"? ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Modifying image data and keeping the data 'correct'.

  1. Modifying image data and keeping the data 'correct'.

    Let's say I have some DICOM data with uncompressed image data in it,
    BitsAllocated = 8, then I modify some of the image data and convert it
    to 16-bit. What all do I need to update to keep everything "correct"?
    Here's what I've come up with:

    - BitsAllocated, BitsStored, HighBit, of course.
    - Image group length size.
    - Pick a new padding value if one was defined originally.
    - Recalculate min/max pixel values.

    Am I missing anything? None of the data I am working with has any
    color LUTs in it so I don't need to worry about that. What about
    window width/center and rescale slope/intercept? How should I handle
    those?

    Thanks,
    Jason


  2. Re: Modifying image data and keeping the data 'correct'.

    On Feb 13, 7:06 pm, jason.cipri...@gmail.com wrote:
    > Let's say I have some DICOM data with uncompressed image data in it,
    > BitsAllocated = 8, then I modify some of the image data and convert it
    > to 16-bit. What all do I need to update to keep everything "correct"?
    > Here's what I've come up with:
    >
    > - BitsAllocated, BitsStored, HighBit, of course.
    > - Image group length size.
    > - Pick a new padding value if one was defined originally.
    > - Recalculate min/max pixel values.
    >
    > Am I missing anything? None of the data I am working with has any
    > color LUTs in it so I don't need to worry about that. What about
    > window width/center and rescale slope/intercept? How should I handle
    > those?


    Hi Jason,

    The subject was discuss earlier this week. I suggested the following
    link:

    http://gdcm.sourceforge.net/wiki/ind...d_DICOM_Images
    (updated with Eric's recent comment).

    Since you are likely to make the pixel data of the derived image to
    be different from the pixel data of the source images (and this
    difference might affect professional interpretation of the image).

    Anyway I will also add your comment about elements related to the
    direct modification of the Pixel Data.

    Thanks
    -Mathieu


  3. Re: Modifying image data and keeping the data 'correct'.

    Hi Jason

    Making the attributes related to the image display pipeline
    work is just one part of the problem.

    A better way to think of this than as what attributes need to
    be changed is what information entities need to be changed.

    Is it the same Patient and Study ? Yes, so none of the
    attributes of the Patient and Study modules need to be
    changed.

    Is it the same Equipment ? No. Therefore all the Equipment
    and Series Module attributes need to be changed.

    Is it a new "procedure step" ? Yes, therefore old procedure
    step related attributes may need to be removed and a new
    procedure step created, or not depending on how the new
    objects are expected to be managed in the PACS. These are
    generally in the Series level modules.

    Is it the same spatial or temporal Frame of Reference ? This
    depends on what you are doing to the image, and if not then
    all the orientation, position and frame of reference attributes
    in appropriate modules may need to be changed, and exactly
    what depends on what SOP Class the image is.

    Is it the same instance ? By definition not in this case,
    so you have to consider all the Image and Instance level
    module attributes. Do acquisition technique attributes
    (like Echo Time of kVP) still apply ? Possibly not if you
    have merged two images. What about relationship to X-Ray
    intensity ? Not if you have inverted the image somehow,
    etc. Have you added burned in annotation ? If so that
    attribute should be set if it wasn't before, etc.

    What about private attributes ? Probably need to remove them
    all if you don't know exactly what they mean and whether or
    not they still apply.

    I.e., there is no simple, general answer to this question,
    since it depends on what you are doing to the images, and
    what SOP Class they are.

    Another way to look at this is as a "pull" rather than a
    "push" problem ... are you "pushing" all the original
    entities and their attributes to the new object and
    removing or replacing what no longer applies, or are
    you creating a new object from scratch and only "pulling"
    those attributes of those entities from the original
    that are the same entity (typically Patient, Study and
    Frame of Reference).

    David

    PS. Why would you want to take perfectly good 8 bit data and
    make it 16 bit in the first place ? I.e., what is the use
    case here, in case we are leading you in the wrong direction
    with too general an answer to too general a question ?

    Mathieu Malaterre wrote:
    > On Feb 13, 7:06 pm, jason.cipri...@gmail.com wrote:
    >> Let's say I have some DICOM data with uncompressed image data in it,
    >> BitsAllocated = 8, then I modify some of the image data and convert it
    >> to 16-bit. What all do I need to update to keep everything "correct"?
    >> Here's what I've come up with:
    >>
    >> - BitsAllocated, BitsStored, HighBit, of course.
    >> - Image group length size.
    >> - Pick a new padding value if one was defined originally.
    >> - Recalculate min/max pixel values.
    >>
    >> Am I missing anything? None of the data I am working with has any
    >> color LUTs in it so I don't need to worry about that. What about
    >> window width/center and rescale slope/intercept? How should I handle
    >> those?

    >
    > Hi Jason,
    >
    > The subject was discuss earlier this week. I suggested the following
    > link:
    >
    > http://gdcm.sourceforge.net/wiki/ind...d_DICOM_Images
    > (updated with Eric's recent comment).
    >
    > Since you are likely to make the pixel data of the derived image to
    > be different from the pixel data of the source images (and this
    > difference might affect professional interpretation of the image).
    >
    > Anyway I will also add your comment about elements related to the
    > direct modification of the Pixel Data.
    >
    > Thanks
    > -Mathieu
    >


  4. Re: Modifying image data and keeping the data 'correct'.

    Thanks for the link, Mathieu, and the detailed reply, David. I
    actually never noticed the responses; gmail can be a bit misleading
    sometimes when you subscribe to groups (and I'm doing this through
    Google groups).

    To answer this question:

    > PS. Why would you want to take perfectly good 8 bit data and
    > make it 16 bit in the first place ? I.e., what is the use
    > case here, in case we are leading you in the wrong direction
    > with too general an answer to too general a question ?


    I'm putting together some software for a client that wants to apply
    certain modifications to DICOM images; some of these modifications can
    make the pixel values larger than the range that 8-bit values can
    store. When that happens and the original data was 8-bit, it needs to
    be converted to 16-bit to hold the new larger value ranges.

    David, a question: Quite honestly, neither I nor the client care about
    keeping the entire file correct. The DICOM specification covers...
    well... a lot (I say that with good amount of bitterness . This
    particular application is being used to modify image data for some
    experiments that only involve the image data itself, and not any of
    the other information stored in the file. So really what I'm trying to
    nail down is the minimal fields I need to modify to allow the image to
    be displayed correctly in some other arbitrary viewer application. The
    private data is already removed when we anonymize the data, so that's
    not a problem. The spatial/temporal reference frames stay the same as
    well, so that's covered. But, for example, the "acquisition technique
    attributes" you mentioned. Those aren't changed, I mean that's still
    how the original images were applied... that's not something you could
    change in an image editor. And in any case, take CT's for example...
    unless I'm mistaken that data is all stored as some values that relate
    to Hounsfield units or something like that, and the "kVp" attribute,
    for example, doesn't change that. I mean, I could randomly generate a
    value for kVp and the image itself would still display correctly
    without changing, all that's lost is information about the acquisition
    technique, which isn't relevant for this particular application. Same
    with fields like, the equipment model and vendor names. And even the
    instance UIDs or whatever... doesn't matter. These modified files
    aren't being sent out for any more professional evaluation -- really
    the only reason we're writing DICOM files back out is so we can
    continue to store things such as slice position and image location in
    the files and have that be meaningful for other existing software that
    we're using that's designed to work on DICOM data.

    Oh and, in this case, it is a "push" more than a "pull". All the
    original entities are copied and modifications are made only to ones
    that are related to the pixel data itself and affected by any changes.
    But it is important to keep the relationship between the pixel values
    and the values they represent the same (what I mean is, if a pixel
    value of 0 actually represents a value of, say, -1024, then 0 should
    still mean -1024 when the modified data is written back out0.

    Thanks,
    Jason


  5. Re: Modifying image data and keeping the data 'correct'.

    Sorry about the double mail; I feel I should clear this part up since
    the -display- of DICOM images is, shall we say, a field in itself:

    > And in any case, take CT's for example...
    > unless I'm mistaken that data is all stored as some values that relate
    > to Hounsfield units or something like that, and the "kVp" attribute,
    > for example, doesn't change that. I mean, I could randomly generate a
    > value for kVp and the image itself would still display correctly
    > without changing, all that's lost is information about the acquisition
    > technique, which isn't relevant for this particular application.


    I said "display correctly" but what I actually meant was "display
    correctly and preserve the meaning of the original values", such as
    the relationship between the stored value and HU, or whatever
    depending on the image type (we deal with MRI data as well). So things
    like the rescale slope and intercept are important to this application
    as well as the pixel values themselves.


+ Reply to Thread