16-bit/sample color image in DICOM? - DICOM

This is a discussion on 16-bit/sample color image in DICOM? - DICOM ; Hi, everyone. I'm new here. Currently I'm writing a generic DICOM loader for my company's project. For RGB DICOM series, I'm wondering if it's possible to have 16 bits or larger data for each RGB component (so that the total ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: 16-bit/sample color image in DICOM?

  1. 16-bit/sample color image in DICOM?

    Hi, everyone. I'm new here. Currently I'm writing a generic DICOM
    loader for my company's project. For RGB DICOM series, I'm wondering
    if it's possible to have 16 bits or larger data for each RGB component
    (so that the total number of bits per pixel is 48+). For example, bits
    allocated = 16, photometric representation = RGB, samples per pixel =
    3. The raw file from my DSLR camera is in that format. But I have
    never seem one in real DICOM file. Anyone has ever bumped into one
    DICOM like that? Or maybe I don't have to worry about this case?

    Thanks for the help!

  2. Re: 16-bit/sample color image in DICOM?

    On Aug 1, 6:51*pm, Mingming wrote:
    > Hi, everyone. I'm new here. Currently I'm writing a generic DICOM
    > loader for my company's project. For RGB DICOM series, I'm wondering
    > if it's possible to have 16 bits or larger data for each RGB component
    > (so that the total number of bits per pixel is 48+). For example, bits
    > allocated = 16, photometric representation = RGB, samples per pixel =
    > 3. The raw file from my DSLR camera is in that format. But I have
    > never seem one in real DICOM file. Anyone has ever bumped into one
    > DICOM like that? Or maybe I don't have to worry about this case?


    I do not think I have seen any of those either: with RGB and Bits
    Allocated=16. But you certainly can have 16bits PALETTE COLOR image,
    where Bits Allocated is 16Bits. For instance:

    http://cvs.creatis.insa-lyon.fr/view...a/rle16loo.dcm

    If you are developing a DICOM viewer, I would like to have your
    opinion on the following DICOM files, that I call GDCM Conformance
    Tests:

    http://sourceforge.net/project/showf...ease_id=616953

    Those are somewhat 'unusual' DICOM files.

    Hoping this will be useful,
    Thanks
    -Mathieu

  3. Re: 16-bit/sample color image in DICOM?

    On Aug 1, 12:51*pm, Mingming wrote:
    > Hi, everyone. I'm new here. Currently I'm writing a generic DICOM
    > loader for my company's project. For RGB DICOM series, I'm wondering
    > if it's possible to have 16 bits or larger data for each RGB component
    > (so that the total number of bits per pixel is 48+). For example, bits
    > allocated = 16, photometric representation = RGB, samples per pixel =
    > 3. The raw file from my DSLR camera is in that format. But I have
    > never seem one in real DICOM file. Anyone has ever bumped into one
    > DICOM like that? Or maybe I don't have to worry about this case?


    DICOM does not have a transfer syntax for RAW images. These are
    proprietary and change per camera model (and sometimes between
    firmware releases for a camera). But there are two potentials that
    might be acceptable for your use:

    JPEG Lossy can go up to 12-bits per color channel. This is lossy, but
    so is the conversion from RAW to RGB grid. RAW images are single
    color samples on a non-overlapping grid. The grid is usually
    hexagonal or rectilinear, but it is definitely not an RGB pixel grid.
    The individual color samples for reasonable priced cameras are
    8-14bits. The conversion from RAW to grid requires interpolation (at
    least). So you might find the conversion from RAW to 12-bit JPEG
    suitable. You will find interoperability problems because common JPEG
    implementations only work up to 8-bit color.

    JPEG 2000 can go up to 16-bits per color channel. This can be either
    lossy or lossless. So you will only suffer the conversion loss
    between RAW and JPEG 2000. Interoperability will be better because
    JPEG 2000 conformance is stricter about supporting the full range, but
    availability of conforming JPEG 2000 implementations may be a problem.

    You should also consider the likely downstream uses of the objects
    that you create. There are limitations placed on some of the standard
    SOP classes. The Ophthalmic Photography images seem similar to what
    you describe in terms of color depth and resolution. But, they also
    include mandatory attributes that only make sense for ophthalmic
    work. The true color Secondary Capture objects are limited to 8-bits
    per channel. Is there is a real clinical need for the added color
    depth? or is this just accomodating the capabilities of newer
    cameras?

    R Horn

+ Reply to Thread