Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Digital Photography > Jpeg vs Jpeg2000 vs HD Photo - Results

Reply
Thread Tools

Jpeg vs Jpeg2000 vs HD Photo - Results

 
 
Sachin Garg
Guest
Posts: n/a
 
      02-07-2008

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
 
Reply With Quote
 
 
 
 
Sky465nm@trline5.org
Guest
Posts: n/a
 
      02-07-2008
Sachin Garg <(E-Mail Removed)> 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.

 
Reply With Quote
 
 
 
 
Sachin Garg
Guest
Posts: n/a
 
      02-07-2008
On Feb 8, 12:38 am, (E-Mail Removed) wrote:
> Sachin Garg <(E-Mail Removed)> 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/wikipedi...onstration.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
 
Reply With Quote
 
Sky465nm@trline5.org
Guest
Posts: n/a
 
      02-07-2008
>> 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.
 
Reply With Quote
 
Sachin Garg
Guest
Posts: n/a
 
      02-07-2008
On Feb 8, 1:20 am, (E-Mail Removed) 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
 
Reply With Quote
 
Alfred Molon
Guest
Posts: n/a
 
      02-07-2008
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
 
Reply With Quote
 
Sachin Garg
Guest
Posts: n/a
 
      02-07-2008

On Feb 8, 2:27 am, Alfred Molon <(E-Mail Removed)> 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
 
Reply With Quote
 
Thomas Richter
Guest
Posts: n/a
 
      02-09-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Sachin Garg <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
new jpeg2000 format Bob Smith Digital Photography 4 04-08-2004 10:42 PM
JAI + JPEG2000 Sebastian Ryszard Kruk Java 1 12-05-2003 09:16 AM
JPEG2000 ASP .Net 0 09-29-2003 05:56 PM
JPEG2000 Java 0 09-29-2003 05:42 PM
where to find DCT/IDCT for JPEG/JPEG2000 VHDL/VERILOG source code? walala VHDL 0 08-01-2003 09:44 PM



Advertisments