Jpeg vs Jpeg2000 vs HD Photo - Results

Discussion in 'Digital Photography' started by Sachin Garg, Feb 7, 2008.

  1. Sachin Garg

    Sachin Garg Guest

    I finally published an image compression benchmark at

    www.imagecompression.info

    Thanks to everyone who helped with all the questions I have been
    posting from time to time, their comments were more helpful than it
    might have looked like.

    To summarize, Jpeg2000 is much slower than hdphoto and jpeg, these
    both have comparable speed. In quality tests, Jpeg 2000 is giving best
    results, with hdphoto usually worse than old jpeg, but sometimes
    better.

    Do let me know if you have any questions or suggestions for improving
    the site or would like to see anything else added to it, its a work in
    progress. I plan to publish more results on various state of the art
    lossy and lossless algorithms over time.

    Thanks again.

    Sachin Garg [India]
    www.sachingarg.com | www.c10n.info
     
    Sachin Garg, Feb 7, 2008
    #1
    1. Advertising

  2. Sachin Garg

    Guest

    Sachin Garg <> wrote:
    >I finally published an image compression benchmark at
    > www.imagecompression.info


    >To summarize, Jpeg2000 is much slower than hdphoto and jpeg, these
    >both have comparable speed. In quality tests, Jpeg 2000 is giving best
    >results, with hdphoto usually worse than old jpeg, but sometimes
    >better.


    Would you say that Jpeg2000 provide an improvement that makes it worthwhile?

    Also a license comparision might be useful. Such that open source 3rd party
    tools may thrive.

    "However, the JPEG committee has also noted that undeclared and obscure
    submarine patents may still present a hazard:

    It is of course still possible that other organizations or individuals may
    claim intellectual property rights that affect implementation of the
    standard, and any implementers are urged to carry out their own searches and
    investigations in this area."

    One also have to consider that the compression algortihms may be assisted by
    hardware solutions (asic/fpga).

    >Do let me know if you have any questions or suggestions for improving
    >the site or would like to see anything else added to it, its a work in
    >progress. I plan to publish more results on various state of the art
    >lossy and lossless algorithms over time.


    Is your "bits-per-pixel" bits per color? ie 8 => 8bit-red 8bit-green 8bit-blue
    Otherwise the quality would be really low in tests.

    Good evaluation btw.
     
    , Feb 7, 2008
    #2
    1. Advertising

  3. Sachin Garg

    Sachin Garg Guest

    On Feb 8, 12:38 am, wrote:
    > Sachin Garg <> wrote:
    > >I finally published an image compression benchmark at
    > > www.imagecompression.info
    > >To summarize, Jpeg2000 is much slower than hdphoto and jpeg, these
    > >both have comparable speed. In quality tests, Jpeg 2000 is giving best
    > >results, with hdphoto usually worse than old jpeg, but sometimes
    > >better.

    >
    > Would you say that Jpeg2000 provide an improvement that makes it worthwhile?


    Its a tricky question to answer, depends on the type of image. On some
    images the improvement is definitely worthwhile but this cannot be
    said for all images.

    Also Jpeg 2000 gives different types of artifacts, so it will also
    depend on personal preference on what looks more visually appealing to
    someone. My tests focus on loss of quality, not on visual appeal.

    I assume everyone here must be familiar with jpeg artifacts (blocks
    etc), for a sample of what Jpeg 2000 does, you can check this (top
    image is lossless, bottom image gives severe "smoothing".)

    http://upload.wikimedia.org/wikipedia/commons/7/78/JPEG_2000_Artifacts_Demonstration.png

    > Also a license comparision might be useful. Such that open source 3rd party
    > tools may thrive.

    []
    > One also have to consider that the compression algortihms may be assisted by
    > hardware solutions (asic/fpga).


    Yep, these factors are important, sometimes more than
    technicalities :)

    > Is your "bits-per-pixel" bits per color? ie 8 => 8bit-red 8bit-green 8bit-blue
    > Otherwise the quality would be really low in tests.


    The lossy tests cover the entire range from minimal-loss (eg, quality
    level 100 for jpeg) to maximum-loss for each codec.

    Some images (like artificial which has no noise) are just too
    compressible while others (like deer) go upto more than 16 bits-per-
    pixel.

    > Good evaluation btw.


    Thanks.

    Sachin Garg [India]
    www.sachingarg.com | www.c10n.info
     
    Sachin Garg, Feb 7, 2008
    #3
  4. Sachin Garg

    Guest

    >> Is your "bits-per-pixel" bits per color? ie 8 => 8bit-red 8bit-green 8bit-blue
    >> Otherwise the quality would be really low in tests.


    >The lossy tests cover the entire range from minimal-loss (eg, quality
    >level 100 for jpeg) to maximum-loss for each codec.


    >Some images (like artificial which has no noise) are just too
    >compressible while others (like deer) go upto more than 16 bits-per-pixel.


    Ah.. so it's not source bits per pixel, but resulting bits/pixel in the
    compressed outout.
     
    , Feb 7, 2008
    #4
  5. Sachin Garg

    Sachin Garg Guest

    On Feb 8, 1:20 am, wrote:
    > >> Is your "bits-per-pixel" bits per color? ie 8 => 8bit-red 8bit-green 8bit-blue
    > >> Otherwise the quality would be really low in tests.

    > >The lossy tests cover the entire range from minimal-loss (eg, quality
    > >level 100 for jpeg) to maximum-loss for each codec.
    > >Some images (like artificial which has no noise) are just too
    > >compressible while others (like deer) go upto more than 16 bits-per-pixel.

    >
    > Ah.. so it's not source bits per pixel, but resulting bits/pixel in the
    > compressed outout.


    Yep, source bits-per-pixel is 24 (8+8+8 rgb).

    Sachin Garg [India]
    www.sachingarg.com | www.c10n.info
     
    Sachin Garg, Feb 7, 2008
    #5
  6. Sachin Garg

    Alfred Molon Guest

    A test I saw years ago showed that at low compression ratios, typical
    for digital photography (1:10 or better) JPEG was at least as good as
    JPEG2000 if not even better.

    Here is one such test (not the one I referred to above):
    http://kt.ijs.si/aleks/jpeg/artifacts.htm

    "... At higher bit rates (3.0 bits/pixel), there are no visible
    differences between JPEG and JPEG2000 ...".
    --

    Alfred Molon
    ------------------------------
    Olympus 50X0, 8080, E3X0, E4X0, E5X0 and E3 forum at
    http://tech.groups.yahoo.com/group/MyOlympus/
    http://myolympus.org/ photo sharing site
     
    Alfred Molon, Feb 7, 2008
    #6
  7. Sachin Garg

    Sachin Garg Guest

    On Feb 8, 2:27 am, Alfred Molon <> wrote:
    > A test I saw years ago showed that at low compression ratios, typical
    > for digital photography (1:10 or better) JPEG was at least as good as
    > JPEG2000 if not even better.
    >
    > Here is one such test (not the one I referred to above):http://kt.ijs.si/aleks/jpeg/artifacts.htm
    >
    > "... At higher bit rates (3.0 bits/pixel), there are no visible
    > differences between JPEG and JPEG2000 ...".


    Yep, that is correct. Difference is less at high bit-rates.

    This can be seen in the charts too, the plotted lines tend to get
    closer at higher bit-rates. Not for all images, but most of them.

    Sachin Garg [India]
    www.sachingarg.com | www.c10n.info
     
    Sachin Garg, Feb 7, 2008
    #7
  8. wrote:
    > Sachin Garg <> wrote:
    >> I finally published an image compression benchmark at
    >> www.imagecompression.info

    >
    >> To summarize, Jpeg2000 is much slower than hdphoto and jpeg, these
    >> both have comparable speed. In quality tests, Jpeg 2000 is giving best
    >> results, with hdphoto usually worse than old jpeg, but sometimes
    >> better.

    >
    > Would you say that Jpeg2000 provide an improvement that makes it worthwhile?


    That really depends. On the image, and on the codec used. Concerning the
    code, one can *definitely* do better than most "free" codes available.
    Most implementations I've seen make the error of optimizing for the mean
    square error (i.e. making the average pixel intensity difference
    minimal), but this correlates bad to human vision, and the "traditional"
    JPEG keeps care for this; you get some kind of "apples vs. oranges"
    comparison then. Free JPEG2000 implementations (the JJ, the Jasper)
    don't. Thus, "you get what you pay for".

    Concerning the image dependency, JPEG2000 works pretty well on large
    images, and on "smooth" images, water, surfaces, sky. It has problems
    (at least the PSNR-optimized versions) on structures or textures, i.e.
    fabric, grass, the canvas of paintings where I personally consider it to
    perform worse than traditional JPEG.

    That said, the "true" advantage of JPEG2000 is really the number of
    features you get, not the advance in compression performance, i.e.
    support for >8bpp, beyond 12bpp JPEG can handle, more components, more
    color spaces, a browsing protocol (JPIP) etc, etc.

    > Also a license comparision might be useful. Such that open source 3rd party
    > tools may thrive.
    >
    > "However, the JPEG committee has also noted that undeclared and obscure
    > submarine patents may still present a hazard:
    >
    > It is of course still possible that other organizations or individuals may
    > claim intellectual property rights that affect implementation of the
    > standard, and any implementers are urged to carry out their own searches and
    > investigations in this area."


    Unfortunately. And unfortunately, that goes to any non-trivial
    technology. Even old JPEG isn't immune (see the trouble with the
    compression labs patent on the VLC in JPEG).

    > One also have to consider that the compression algortihms may be assisted by
    > hardware solutions (asic/fpga).


    There are hardware versions available for both formats, actually. For
    JPEG since a long time now, for JPEG2000 for example by Analog Devices.

    So long,
    Thomas
     
    Thomas Richter, Feb 9, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bob Smith

    new jpeg2000 format

    Bob Smith, Apr 8, 2004, in forum: Digital Photography
    Replies:
    4
    Views:
    620
    Michael Schnell
    Apr 8, 2004
  2. K2

    LuraWave JPEG2000 images are blurry

    K2, Jun 8, 2004, in forum: Digital Photography
    Replies:
    107
    Views:
    9,694
    Guido Vollbeding
    Jun 17, 2004
  3. Steve

    Can JPEG2000 image contain embedded audio ?

    Steve, Mar 21, 2005, in forum: Digital Photography
    Replies:
    2
    Views:
    454
    Bill Tuthill
    Mar 22, 2005
  4. Sachin Garg

    Jpeg2000 in firefox, finally

    Sachin Garg, Apr 14, 2007, in forum: Digital Photography
    Replies:
    6
    Views:
    5,923
    Bill Tuthill
    Apr 16, 2007
  5. Thomas Richter

    Exif Metadata in JPEG2000: Request for Comments

    Thomas Richter, Jan 9, 2008, in forum: Digital Photography
    Replies:
    5
    Views:
    1,502
    Roy G
    Jul 25, 2008
Loading...

Share This Page