JPEG implementation in DICOM - DICOM

This is a discussion on JPEG implementation in DICOM - DICOM ; Hello, I have been browsing the web to find a solution but couldn't find one clearly. I hope you guys can guve me some hints on that. My problem is the following, I am working on gdcm(1) (yet another dicom ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: JPEG implementation in DICOM

  1. JPEG implementation in DICOM

    Hello,

    I have been browsing the web to find a solution but couldn't find one
    clearly. I hope you guys can guve me some hints on that.

    My problem is the following, I am working on gdcm(1) (yet another dicom
    implementation), and for now we are using ijg (from ijg.org) and
    cornwell lossless jpeg.

    If my understanding is correct:

    - Lots of people have patch the official ijg implementation using the
    unofficial ls patch(2), and the arithmetic patch(3). In the case of
    dcmtk, they even fix bugs from those patches (correct?). Osirix seems to
    have followed the same approach. But it seems like there is two
    different lossless jpeg, and the one defined in DICOM is different than
    the one implemented in (2).

    - David Clunie (dicom3tools) rather use Stanford PVRG JPEG CODEC, since
    (and it was confirm on various web search) that the Cornell Lossless is
    buggy (correct?).


    So which jpeg implementation would you suggest for having *all* the
    DICOM jpeg possibilities. Taking into account that at some point it
    should support jpeg 2000.

    Thanks
    Mathieu

    As a side note the 'DICOM version of Cornell Lossless JPEG from Brown:'
    seems to have despear: ftp://ftp.xray.hmc.psu.edu/dicom_software/Brown
    Does anyone has a copy ?

    Refs:
    (1) http://www.creatis.insa-lyon.fr/Public/Gdcm/
    (2) http://www.oceana.com/ftp/ljpeg/
    (3) http://sylvana.net/jpeg-ari/


  2. Re: JPEG implementation in DICOM

    Mathieu Malaterre wrote:

    > - Lots of people have patch the official ijg implementation using the
    > unofficial ls patch(2), and the arithmetic patch(3). In the case of
    > dcmtk, they even fix bugs from those patches (correct?).


    Correct, although we don't use the arithmetic patch, which is not
    compatible with the modifications introduced by the "lossless" patch.

    We also compile three versions of the IJG library (for 8, 12, 16
    bits/sample) because the bit depth is a compile time constant in this
    library.

    > But it seems like there is two different lossless jpeg, and the one
    > defined in DICOM is different than
    > the one implemented in (2).


    No. There is only one "lossless JPEG", and incompatible compressed
    streams can only be caused by buggy software.

    > - David Clunie (dicom3tools) rather use Stanford PVRG JPEG CODEC, since
    > (and it was confirm on various web search) that the Cornell Lossless is
    > buggy (correct?).


    The Cornell codec is known to be faulty for images with more than 8 bits
    per sample, although many people certainly have written patches for that
    as well.

    > So which jpeg implementation would you suggest for having *all* the
    > DICOM jpeg possibilities. Taking into account that at some point it
    > should support jpeg 2000.


    There is no ideal "one fits all", at least in the freeware domain.
    JPEG 2000 is not supported by any of the libraries you mentioned (and
    probably never will be). The JPEG 2000 freeware implementations that are
    available also have their pros and cons (and bugs).

    > As a side note the 'DICOM version of Cornell Lossless JPEG from Brown:'
    > seems to have despear: ftp://ftp.xray.hmc.psu.edu/dicom_software/Brown
    > Does anyone has a copy ?


    There is a mirror of the old psu.edu FTP site on our FTP server:
    ftp://dicom.offis.de/pub/dicom/mirro...oftware/Brown/

    Regards,
    Marco Eichelberg
    OFFIS

  3. Re: JPEG implementation in DICOM

    Marco,

    Thanks a lot for your answer this is really usefull.

    A few remaing questions then:
    - were you able to read *and* write all possible dicom image using ijg
    + lossless patch (+ your bugfixes) ? Meaning the ijg lib + ls-patch
    should be enough and would not require no other jpeg library (if we
    except jpeg 2000) ?
    - I believe dcmtk is distributed with a BSD like license, thus as long
    as we provide your copyright in the gdcm code, we should be able to use
    your bugfixes ?

    One final thing about the lossless jpeg compression, are you saying
    David Clunie is wrong in his post (*) or is there something I really
    misunderstood in the lossless thingy ?

    http://groups.google.com/groups?hl=e...nadoo.fr#link3


    Thanks again
    Mathieu

    In case the link wouldn't work:
    (*)
    From: David Clunie (dclunie@idt.net)
    Subject: Re: JPEG-LS

    View this article only
    Newsgroups: comp.protocols.dicom
    Date: 1999/07/18

    Hi Philippe, Todor

    JPEG-LS (ISO 14495-1) is not the same as JPEG lossless (ISO 10918-1)
    as used in DICOM. It is a completely new compression scheme. I have
    proposed adding it as a DICOM transfer syntax (see CP 174):

    http://medical.nema.org/dicom/cp/cp174_02.pdf

    I have source code for this on my web site. Better code is available
    from HP who invented most of it. See for links:

    http://idt.net/~dclunie/medical-imag...tml#SourceJPEG

    david




    Marco Eichelberg wrote:
    > Mathieu Malaterre wrote:
    >
    >> - Lots of people have patch the official ijg implementation using the
    >> unofficial ls patch(2), and the arithmetic patch(3). In the case of
    >> dcmtk, they even fix bugs from those patches (correct?).

    >
    >
    > Correct, although we don't use the arithmetic patch, which is not
    > compatible with the modifications introduced by the "lossless" patch.
    >
    > We also compile three versions of the IJG library (for 8, 12, 16
    > bits/sample) because the bit depth is a compile time constant in this
    > library.
    >
    >> But it seems like there is two different lossless jpeg, and the one

    >
    > > defined in DICOM is different than

    >
    >> the one implemented in (2).

    >
    >
    > No. There is only one "lossless JPEG", and incompatible compressed
    > streams can only be caused by buggy software.
    >
    >> - David Clunie (dicom3tools) rather use Stanford PVRG JPEG CODEC,
    >> since (and it was confirm on various web search) that the Cornell
    >> Lossless is buggy (correct?).

    >
    >
    > The Cornell codec is known to be faulty for images with more than 8 bits
    > per sample, although many people certainly have written patches for that
    > as well.
    >
    >> So which jpeg implementation would you suggest for having *all* the
    >> DICOM jpeg possibilities. Taking into account that at some point it
    >> should support jpeg 2000.

    >
    >
    > There is no ideal "one fits all", at least in the freeware domain.
    > JPEG 2000 is not supported by any of the libraries you mentioned (and
    > probably never will be). The JPEG 2000 freeware implementations that are
    > available also have their pros and cons (and bugs).
    >
    >> As a side note the 'DICOM version of Cornell Lossless JPEG from
    >> Brown:' seems to have despear:
    >> ftp://ftp.xray.hmc.psu.edu/dicom_software/Brown
    >> Does anyone has a copy ?

    >
    >
    > There is a mirror of the old psu.edu FTP site on our FTP server:
    > ftp://dicom.offis.de/pub/dicom/mirro...oftware/Brown/
    >
    > Regards,
    > Marco Eichelberg
    > OFFIS


  4. Re: JPEG implementation in DICOM

    Marco,

    Thanks a lot for your answer this is really usefull.

    A few remaing questions then:
    - were you able to read *and* write all possible dicom image using ijg
    + lossless patch (+ your bugfixes) ? Meaning the ijg lib + ls-patch
    should be enough and would not require no other jpeg library (if we
    except jpeg 2000) ?
    - I believe dcmtk is distributed with a BSD like license, thus as long
    as we provide your copyright in the gdcm code, we should be able to use
    your bugfixes ?

    One final thing about the lossless jpeg compression, are you saying
    David Clunie is wrong in his post (*) or is there something I really
    misunderstood in the lossless thingy ?

    http://groups.google.com/groups?hl=e...nadoo.fr#link3


    Thanks again
    Mathieu

    In case the link wouldn't work:
    (*)
    From: David Clunie (dclunie@idt.net)
    Subject: Re: JPEG-LS

    View this article only
    Newsgroups: comp.protocols.dicom
    Date: 1999/07/18

    Hi Philippe, Todor

    JPEG-LS (ISO 14495-1) is not the same as JPEG lossless (ISO 10918-1)
    as used in DICOM. It is a completely new compression scheme. I have
    proposed adding it as a DICOM transfer syntax (see CP 174):

    http://medical.nema.org/dicom/cp/cp174_02.pdf

    I have source code for this on my web site. Better code is available
    from HP who invented most of it. See for links:

    http://idt.net/~dclunie/medical-imag...tml#SourceJPEG

    david




    Marco Eichelberg wrote:
    > Mathieu Malaterre wrote:
    >
    >> - Lots of people have patch the official ijg implementation using the
    >> unofficial ls patch(2), and the arithmetic patch(3). In the case of
    >> dcmtk, they even fix bugs from those patches (correct?).

    >
    >
    > Correct, although we don't use the arithmetic patch, which is not
    > compatible with the modifications introduced by the "lossless" patch.
    >
    > We also compile three versions of the IJG library (for 8, 12, 16
    > bits/sample) because the bit depth is a compile time constant in this
    > library.
    >
    >> But it seems like there is two different lossless jpeg, and the one

    >
    > > defined in DICOM is different than

    >
    >> the one implemented in (2).

    >
    >
    > No. There is only one "lossless JPEG", and incompatible compressed
    > streams can only be caused by buggy software.
    >
    >> - David Clunie (dicom3tools) rather use Stanford PVRG JPEG CODEC,
    >> since (and it was confirm on various web search) that the Cornell
    >> Lossless is buggy (correct?).

    >
    >
    > The Cornell codec is known to be faulty for images with more than 8 bits
    > per sample, although many people certainly have written patches for that
    > as well.
    >
    >> So which jpeg implementation would you suggest for having *all* the
    >> DICOM jpeg possibilities. Taking into account that at some point it
    >> should support jpeg 2000.

    >
    >
    > There is no ideal "one fits all", at least in the freeware domain.
    > JPEG 2000 is not supported by any of the libraries you mentioned (and
    > probably never will be). The JPEG 2000 freeware implementations that are
    > available also have their pros and cons (and bugs).
    >
    >> As a side note the 'DICOM version of Cornell Lossless JPEG from
    >> Brown:' seems to have despear:
    >> ftp://ftp.xray.hmc.psu.edu/dicom_software/Brown
    >> Does anyone has a copy ?

    >
    >
    > There is a mirror of the old psu.edu FTP site on our FTP server:
    > ftp://dicom.offis.de/pub/dicom/mirro...oftware/Brown/
    >
    > Regards,
    > Marco Eichelberg
    > OFFIS


  5. Re: JPEG implementation in DICOM

    Mathieu

    Both Marco and David are right as usual.

    IJG software now includes JPEG lossless decoding, based on Stanford
    implementation. This is what is used by DcmTk.
    Standford implementation is known to be much more reliable than
    Cornell implementation which has some bugs and memory leaks for > 8
    bits per pixel data but those can be (no so) easily fixed.

    JPEG Lossless defined in the standard as 1.2.840.10008.etc.70 has
    nothing to do with JPEG-LS which seems much more powerful, but does
    not have any full public domain implementation (excepted David Clunie
    implementation that only deals with grayscale images I think).

    JPEG 2k is also another thing and leads to other Xfer syntaxes.

    Gilles


    Mathieu Malaterre wrote in message news:<416C7FDF.9020609@Mfree.fr>...
    > Marco,
    >
    > Thanks a lot for your answer this is really usefull.
    >
    > A few remaing questions then:
    > - were you able to read *and* write all possible dicom image using ijg
    > + lossless patch (+ your bugfixes) ? Meaning the ijg lib + ls-patch
    > should be enough and would not require no other jpeg library (if we
    > except jpeg 2000) ?
    > - I believe dcmtk is distributed with a BSD like license, thus as long
    > as we provide your copyright in the gdcm code, we should be able to use
    > your bugfixes ?
    >
    > One final thing about the lossless jpeg compression, are you saying
    > David Clunie is wrong in his post (*) or is there something I really
    > misunderstood in the lossless thingy ?
    >
    > http://groups.google.com/groups?hl=e...nadoo.fr#link3
    >
    >
    > Thanks again
    > Mathieu
    >


  6. Re: JPEG implementation in DICOM

    Mathieu Malaterre wrote:

    > - were you able to read *and* write all possible dicom image using
    > ijg + lossless patch (+ your bugfixes) ? Meaning the ijg lib + ls-patch
    > should be enough and would not require no other jpeg library (if we
    > except jpeg 2000) ?


    With our patches I have been able to decode all DICOM images compressed
    with lossless JPEG except for images with the well-known "GE bug" for
    which we have never bothered to develop a work-around in DCMTK.

    Regarding "write", there is only a single drawback of the IJG library
    I am aware of. Lossless JPEG allows compressed bitstreams to have
    anything between 2 and 16 bits per sample. The IJG library only supports
    8, 12 and 16 upon compression (decompression works).
    In principle it should not be a big problem, say, to encode a 10-bit
    image as a 12-bit JPEG bitstream, except for a very small compression
    ratio penalty and the possibility that a few decoders might be confused
    when reading such an image (never found an example for that to be the
    case, though). In practice, lossless JPEG is mostly used for cath lab
    XA objects which are 8 bits/sample anyway.

    > - I believe dcmtk is distributed with a BSD like license, thus as
    > long as we provide your copyright in the gdcm code, we should be able to
    > use your bugfixes ?


    Yes. Both DCMTK and the IJG library are available under a BSD license.

    > One final thing about the lossless jpeg compression, are you saying
    > David Clunie is wrong in his post (*) or is there something I really
    > misunderstood in the lossless thingy ?


    David speaks about "JPEG LS", which has absolutely nothing in common
    with JPEG lossless. You have to understand that "JPEG" is the name of
    a committee, not a standard, and there are various standards developed
    by the JPEG committee, including
    - JPEG (ISO 10918-1) which includes both a lossy
    and a lossless mode. This is what we're talking about here.
    - JPEG-LS (ISO 14495-1), based on the HP LOCO-I algorithm
    - JPEG 2000 (ISO 15444-1), based on wavelet compression. This also
    defines a lossy and a lossless mode.

    Regards,
    Marco Eichelberg
    OFFIS

  7. Re: JPEG implementation in DICOM

    Marco Eichelberg wrote:
    > Mathieu Malaterre wrote:
    >
    >> - were you able to read *and* write all possible dicom image
    >> using ijg + lossless patch (+ your bugfixes) ? Meaning the ijg lib +
    >> ls-patch should be enough and would not require no other jpeg library
    >> (if we except jpeg 2000) ?

    >
    >
    > With our patches I have been able to decode all DICOM images compressed
    > with lossless JPEG except for images with the well-known "GE bug" for
    > which we have never bothered to develop a work-around in DCMTK.
    >
    > Regarding "write", there is only a single drawback of the IJG library
    > I am aware of. Lossless JPEG allows compressed bitstreams to have
    > anything between 2 and 16 bits per sample. The IJG library only supports
    > 8, 12 and 16 upon compression (decompression works).
    > In principle it should not be a big problem, say, to encode a 10-bit
    > image as a 12-bit JPEG bitstream, except for a very small compression
    > ratio penalty and the possibility that a few decoders might be confused
    > when reading such an image (never found an example for that to be the
    > case, though). In practice, lossless JPEG is mostly used for cath lab
    > XA objects which are 8 bits/sample anyway.
    >
    >> - I believe dcmtk is distributed with a BSD like license, thus as
    >> long as we provide your copyright in the gdcm code, we should be able
    >> to use your bugfixes ?

    >
    >
    > Yes. Both DCMTK and the IJG library are available under a BSD license.
    >
    >> One final thing about the lossless jpeg compression, are you
    >> saying David Clunie is wrong in his post (*) or is there something I
    >> really misunderstood in the lossless thingy ?

    >
    >
    > David speaks about "JPEG LS", which has absolutely nothing in common
    > with JPEG lossless. You have to understand that "JPEG" is the name of
    > a committee, not a standard, and there are various standards developed
    > by the JPEG committee, including
    > - JPEG (ISO 10918-1) which includes both a lossy
    > and a lossless mode. This is what we're talking about here.
    > - JPEG-LS (ISO 14495-1), based on the HP LOCO-I algorithm
    > - JPEG 2000 (ISO 15444-1), based on wavelet compression. This also
    > defines a lossy and a lossless mode.


    Thanks again for your comments this is extremly usefull, believe me.
    Anyway I have sum up the result of my work here:

    http://www.creatis.insa-lyon.fr/~malaterre/jpeg/

    And now I have a complete process from ijg + ls-patch + dcmtk-patch +
    various warnings-fixes-patch to produce 3 jpeg libraries... that was
    painfull !

    BTW I have added your copyright within gdcm in
    gdcm/src/jpeg/libijg/COPYRIGHT.dcmtk and added a special mention for you
    in the README.GDCM.txt file.

    Thanks again for your help
    Mathieu

+ Reply to Thread