Possible bug in sample file - DICOM

This is a discussion on Possible bug in sample file - DICOM ; [[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] While going through the test data sets kindly provided by Dr Clunie I encountered a minor problem with the RG3_JPLY file from ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Possible bug in sample file

  1. Possible bug in sample file

    [[ This message was both posted and mailed: see
    the "To," "Cc," and "Newsgroups" headers for details. ]]


    While going through the test data sets kindly provided by Dr Clunie I
    encountered a minor problem with the RG3_JPLY file from the
    ftp://medical.nema.org/MEDICAL/Dicom...mples_jpeg.tar
    file set.

    This file specifies 10 bits stored (data element 0x0028, 0x0101), so
    the pixel values should have an allowed range of 0 to 1023 (1024
    values). However, this file's pixel data range from 0 to 1024. The
    discrepancy was caught by a sanity check in our code for the range
    actual pixel values (as in the data) vs the nominally allowed ones (as
    calculated from the bits used data element).

    The decompression was performed with the 12 bit version the JPEG_2B
    library. With the 16 bit version of the library the resulting pixel
    value range was 30711 to 31744, i.e. 1034 values. In both cases the
    resulting image is visually identical to the reference image RG3_UNC
    available at
    ftp://medical.nema.org/MEDICAL/Dicom...ples_refanddir.
    tar.bz2 .

    This is most likely a decompression artifact caused by the fact that
    the available output range from the jpeg library is 12/16 bits
    respectively.

    This particular case is not much of a problem, but does raise the
    question of how one (an application or toolkit) is supposed to handle
    such situations.

    Is a re-scaling of the data values to the correct range appropriate or
    could one just ignore the overshoot (since the data values would be
    embedded in a 16 bit buffer anyway) or maybe clamp the overshooting
    pixel values to the maximum allowed? I'm inclined to prefer the second
    or third approach because (not quite sure which one yet) because
    a. Re-scaling by 1023/newMaxPixelValue would probably cause more
    artifacts due to aliasing of the data values.
    b. More significantly, re-scaling would move the mean of the pixel
    values, thus introducing a systematic bias to the resulting image.

    Best regards to all,

    Tony Patrinos, PhD
    Escape Information Services
    http://www.escape.gr/dicom/

  2. Re: Possible bug in sample file

    Anthony Patrinos wrote in message news:<031120041310377554%patrinos@escape.gr>...
    > [[ This message was both posted and mailed: see
    > the "To," "Cc," and "Newsgroups" headers for details. ]]
    >
    >
    > While going through the test data sets kindly provided by Dr Clunie I
    > encountered a minor problem with the RG3_JPLY file from the
    > ftp://medical.nema.org/MEDICAL/Dicom...mples_jpeg.tar
    > file set.
    >
    > This file specifies 10 bits stored (data element 0x0028, 0x0101), so
    > the pixel values should have an allowed range of 0 to 1023 (1024
    > values). However, this file's pixel data range from 0 to 1024. The
    > discrepancy was caught by a sanity check in our code for the range
    > actual pixel values (as in the data) vs the nominally allowed ones (as
    > calculated from the bits used data element).
    >
    > The decompression was performed with the 12 bit version the JPEG_2B
    > library. With the 16 bit version of the library the resulting pixel
    > value range was 30711 to 31744, i.e. 1034 values. In both cases the
    > resulting image is visually identical to the reference image RG3_UNC
    > available at
    > ftp://medical.nema.org/MEDICAL/Dicom...ples_refanddir.
    > tar.bz2 .
    >
    > This is most likely a decompression artifact caused by the fact that
    > the available output range from the jpeg library is 12/16 bits
    > respectively.
    >
    > This particular case is not much of a problem, but does raise the
    > question of how one (an application or toolkit) is supposed to handle
    > such situations.
    >
    > Is a re-scaling of the data values to the correct range appropriate or
    > could one just ignore the overshoot (since the data values would be
    > embedded in a 16 bit buffer anyway) or maybe clamp the overshooting
    > pixel values to the maximum allowed? I'm inclined to prefer the second
    > or third approach because (not quite sure which one yet) because
    > a. Re-scaling by 1023/newMaxPixelValue would probably cause more
    > artifacts due to aliasing of the data values.
    > b. More significantly, re-scaling would move the mean of the pixel
    > values, thus introducing a systematic bias to the resulting image.
    >
    > Best regards to all,
    >
    > Tony Patrinos, PhD
    > Escape Information Services
    > http://www.escape.gr/dicom/



    According to my understanding, when the header says it use 10 bits,
    your application should mask the unused bits to get correct pixel
    value.

  3. Re: Possible bug in sample file

    Anthony Patrinos wrote:
    > While going through the test data sets kindly provided by Dr Clunie I
    > encountered a minor problem with the RG3_JPLY file from the
    > ftp://medical.nema.org/MEDICAL/Dicom...mples_jpeg.tar
    > file set.
    > This file specifies 10 bits stored (data element 0x0028, 0x0101), so
    > the pixel values should have an allowed range of 0 to 1023 (1024
    > values). However, this file's pixel data range from 0 to 1024.


    You are raising an interesting point that is probably not mentioned
    anywhere in the standard. Lossy compression can cause slight deviations
    in pixel values. If you apply a 12-bit compression to image data that
    only uses pixel values 0..1023, then there is no guarantee that the
    decompressed image is still in the range 0..1023.
    In my opinion an appropriate way to handle this problem would either be
    to scale up the source image to 12 bits (if allowed by the UID rules
    etc.) or to manually clamp the decompressed values into the source range
    after decompression (which is what the codec does for 12-bit data).

    Regards,
    Marco Eichelberg
    OFFIS

  4. Re: Possible bug in sample file

    In article <86aec5a6.0411042109.558b1ad7@posting.google.com>,
    www.fruitfruit.com wrote:

    > Anthony Patrinos wrote in message
    > news:<031120041310377554%patrinos@escape.gr>...
    > > [[ This message was both posted and mailed: see
    > > the "To," "Cc," and "Newsgroups" headers for details. ]]
    > >
    > >
    > > While going through the test data sets kindly provided by Dr Clunie I
    > > encountered a minor problem with the RG3_JPLY file from the
    > > ftp://medical.nema.org/MEDICAL/Dicom...mples_jpeg.tar
    > > file set.
    > >
    > > This file specifies 10 bits stored (data element 0x0028, 0x0101), so
    > > the pixel values should have an allowed range of 0 to 1023 (1024
    > > values). However, this file's pixel data range from 0 to 1024. The
    > > discrepancy was caught by a sanity check in our code for the range
    > > actual pixel values (as in the data) vs the nominally allowed ones (as
    > > calculated from the bits used data element).
    > >
    > > The decompression was performed with the 12 bit version the JPEG_2B
    > > library. With the 16 bit version of the library the resulting pixel
    > > value range was 30711 to 31744, i.e. 1034 values. In both cases the
    > > resulting image is visually identical to the reference image RG3_UNC
    > > available at
    > > ftp://medical.nema.org/MEDICAL/Dicom...ples_refanddir.
    > > tar.bz2 .
    > >
    > > This is most likely a decompression artifact caused by the fact that
    > > the available output range from the jpeg library is 12/16 bits
    > > respectively.
    > >
    > > This particular case is not much of a problem, but does raise the
    > > question of how one (an application or toolkit) is supposed to handle
    > > such situations.
    > >
    > > Is a re-scaling of the data values to the correct range appropriate or
    > > could one just ignore the overshoot (since the data values would be
    > > embedded in a 16 bit buffer anyway) or maybe clamp the overshooting
    > > pixel values to the maximum allowed? I'm inclined to prefer the second
    > > or third approach because (not quite sure which one yet) because
    > > a. Re-scaling by 1023/newMaxPixelValue would probably cause more
    > > artifacts due to aliasing of the data values.
    > > b. More significantly, re-scaling would move the mean of the pixel
    > > values, thus introducing a systematic bias to the resulting image.
    > >
    > > Best regards to all,
    > >
    > > Tony Patrinos, PhD
    > > Escape Information Services
    > > http://www.escape.gr/dicom/

    >
    >
    > According to my understanding, when the header says it use 10 bits,
    > your application should mask the unused bits to get correct pixel
    > value.



    In article , Marco
    Eichelberg wrote:
    ....
    > You are raising an interesting point that is probably not mentioned
    > anywhere in the standard. Lossy compression can cause slight deviations
    > in pixel values. If you apply a 12-bit compression to image data that
    > only uses pixel values 0..1023, then there is no guarantee that the
    > decompressed image is still in the range 0..1023.
    > In my opinion an appropriate way to handle this problem would either be
    > to scale up the source image to 12 bits (if allowed by the UID rules
    > etc.) or to manually clamp the decompressed values into the source range
    > after decompression (which is what the codec does for 12-bit data).
    >
    > Regards,
    > Marco Eichelberg
    > OFFIS



    Thanks to onega and Marco for replying. I'm inclined to believe that
    the clamping approach is the most correct for the reason Marco
    mentions. However, perhaps the standard should include an appropriate
    clarification.

    Best regards to all,
    Tony Patrinos, PhD
    Escape Information Services
    http://www.escape.gr/dicom/

+ Reply to Thread