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.
Sachin Garg <schngrg@gmail.com> 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.
On Feb 8, 12:38 am, Sky46...@trline5.org wrote:
> Sachin Garg <schn...@gmail.com> 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".)
> 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.
On Feb 8, 1:20 am, Sky46...@trline5.org 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.
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.
On Feb 8, 2:27 am, Alfred Molon <alfred_mo...@yahoo.com> 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.
Sky465nm@trline5.org wrote:
> Sachin Garg <schngrg@gmail.com> 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.
Jpeg vs Jpeg2000 vs HD Photo - Results 
Linear Mode
