JPEGLS / D Clunie dataset - DICOM

This is a discussion on JPEGLS / D Clunie dataset - DICOM ; Hello, I am working on getting gdcm to support jpegls, and currently I am playing with a DICOM file from D. Clunie dataset: http://www.creatis.insa-lyon.fr/~mal...E_CT1_JLSN.dcm This file has two jpegls fragments where the lenght -as read by gdcm- are: #1 65536 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: JPEGLS / D Clunie dataset

  1. JPEGLS / D Clunie dataset

    Hello,

    I am working on getting gdcm to support jpegls, and currently I am
    playing with a DICOM file from D. Clunie dataset:

    http://www.creatis.insa-lyon.fr/~mal...E_CT1_JLSN.dcm

    This file has two jpegls fragments where the lenght -as read by gdcm- are:

    #1 65536
    #2 19536
    --------
    85072

    So far so good, but when I read the pixel data length I find: 85104.

    Could someone confirm the values read ? Am I missreading something ? If
    not why is there a difference of 32 bytes ?

    Thanks
    Mathieu

  2. Re: JPEGLS / D Clunie dataset

    Mathieu Malaterre wrote:
    > Hello,
    >
    > I am working on getting gdcm to support jpegls, and currently I am
    > playing with a DICOM file from D. Clunie dataset:
    >
    > http://www.creatis.insa-lyon.fr/~mal...E_CT1_JLSN.dcm
    >
    > This file has two jpegls fragments where the lenght -as read by
    > gdcm- are:
    >
    > #1 65536
    > #2 19536
    > --------
    > 85072
    >
    > So far so good, but when I read the pixel data length I find: 85104.
    >
    > Could someone confirm the values read ? Am I missreading something ?
    > If not why is there a difference of 32 bytes ?


    Hi Mathieu

    I presume this is the same file as in the set of test images
    on the NEMA server, specifically IMAGES/JLSN/CT1_JLSN.

    A dump of the Pixel Data attribute and contents shows:

    @0x000019a6: (0x7fe0,0x0010) OX Pixel Data VR= VL=<0xffffffff> []
    @0x000019b2: (0xfffe,0xe000) NONE Item VR=<> VL=<0x0000> []
    @0x000019ba: (0xfffe,0xe000) NONE Item VR=<> VL=<0x10000> [] # skipping ...
    @0x000119c2: (0xfffe,0xe000) NONE Item VR=<> VL=<0x4c50> [] # skipping ...
    @0x0001661a: (0xfffe,0xe0dd) NONE Sequence Delimitation Item VR=<> VL=<0x0000> []

    When I run dctoraw to extract the bytes from the Pixel Data
    items, I get:

    UnencapsulatePixelData::read Item Tag length=0x0 (0 dec)
    UnencapsulatePixelData::read Item Tag length=0x10000 (65536 dec)
    UnencapsulatePixelData::read Item Tag length=0x4c50 (19536 dec)

    and the resulting raw binary file is 85072 bytes long, as expected,
    and starts and ends with the following bytes:

    0000000 ffd8 fff7 000b 1002 0002 0001 0111 00ff
    0000010 f800 0d01 ffff 001e 0057 0130 0040 ffda
    ....
    0014c30 d554 a94d badc d3da 5a58 a023 ad00 c800
    0014c40 0000 0000 010e 6423 0c61 8c52 70ff d9ff
    0014c50

    I presume you are removing the Item tags and the Sequence Delimitation
    item at the end, each of which occupies 8 bytes (and four of them would
    account for your file being 32 bytes too long, if you are not removing
    them).

    This problem would apply to any encapsulated transfer syntax.

    David

  3. Re: JPEGLS / D Clunie dataset


    > and the resulting raw binary file is 85072 bytes long, as expected,
    > and starts and ends with the following bytes:
    >
    > 0000000 ffd8 fff7 000b 1002 0002 0001 0111 00ff
    > 0000010 f800 0d01 ffff 001e 0057 0130 0040 ffda
    > ...
    > 0014c30 d554 a94d badc d3da 5a58 a023 ad00 c800
    > 0014c40 0000 0000 010e 6423 0c61 8c52 70ff d9ff
    > 0014c50


    Excellent that's what I am reading:

    http://www.creatis.insa-lyon.fr/~mal...E_CT1_JLSN.jpg

    did anyone of you ever play with the UBC implementation of jpegls. I am
    simply converting this image to pgm and neither gimp or imagemagick
    understand the pgm...

    I'll keep investigating, but at least I know my input is right,

    Thanks again David,
    Mathieu

  4. Re: JPEGLS / D Clunie dataset

    Mathieu Malaterre wrote:
    >
    >> and the resulting raw binary file is 85072 bytes long, as expected,
    >> and starts and ends with the following bytes:
    >>
    >> 0000000 ffd8 fff7 000b 1002 0002 0001 0111 00ff
    >> 0000010 f800 0d01 ffff 001e 0057 0130 0040 ffda
    >> ...
    >> 0014c30 d554 a94d badc d3da 5a58 a023 ad00 c800
    >> 0014c40 0000 0000 010e 6423 0c61 8c52 70ff d9ff
    >> 0014c50

    >
    >
    > Excellent that's what I am reading:
    >
    > http://www.creatis.insa-lyon.fr/~mal...E_CT1_JLSN.jpg
    >
    > did anyone of you ever play with the UBC implementation of jpegls. I am
    > simply converting this image to pgm and neither gimp or imagemagick
    > understand the pgm...
    >
    > I'll keep investigating, but at least I know my input is right,



    Nevermind seems like:

    ../bin/locod /tmp/D_CLUNIE_CT1_JLSN.jpg
    convert outfile1.out my.jpg

    is working !

    Ok let's go back to work, sorry for the noise
    Mathieu

  5. Re: JPEGLS / D Clunie dataset

    Mathieu Malaterre wrote:
    >
    >> and the resulting raw binary file is 85072 bytes long, as expected,
    >> and starts and ends with the following bytes:
    >>
    >> 0000000 ffd8 fff7 000b 1002 0002 0001 0111 00ff
    >> 0000010 f800 0d01 ffff 001e 0057 0130 0040 ffda
    >> ...
    >> 0014c30 d554 a94d badc d3da 5a58 a023 ad00 c800
    >> 0014c40 0000 0000 010e 6423 0c61 8c52 70ff d9ff
    >> 0014c50

    >
    >
    > Excellent that's what I am reading:
    >
    > http://www.creatis.insa-lyon.fr/~mal...E_CT1_JLSN.jpg
    >
    > did anyone of you ever play with the UBC implementation of jpegls. I am
    > simply converting this image to pgm and neither gimp or imagemagick
    > understand the pgm...
    >
    > I'll keep investigating, but at least I know my input is right,



    Nevermind seems like:

    ../bin/locod /tmp/D_CLUNIE_CT1_JLSN.jpg
    convert outfile1.out my.jpg

    is working !

    Ok let's go back to work, sorry for the noise
    Mathieu

+ Reply to Thread