Thumb database image format... More investiguation

[Gilles Caulier-4]

Hi all,

I just perform some in-deep test with more image to check which image
format we must use to host in future thumbnails database.

From a space disk viewpoint, it's clear :

[TestDBThumb]$ du -c *-q100.jpg
68K     01-q100.jpg
52K     02-q100.jpg
124K    03-q100.jpg
56K     04-q100.jpg
72K     05-q100.jpg
56K     06-q100.jpg
88K     07-q100.jpg
84K     08-q100.jpg
84K     09-q100.jpg
116K    10-q100.jpg
800K    total

[TestDBThumb]$ du -c *-q85.jpg
16K     01-q85.jpg
12K     02-q85.jpg
36K     03-q85.jpg
12K     04-q85.jpg
16K     05-q85.jpg
16K     06-q85.jpg
28K     07-q85.jpg
20K     08-q85.jpg
24K     09-q85.jpg
36K     10-q85.jpg
216K    total

[TestDBThumb]$ du -c *.jp2
72K     01.jp2
52K     02.jp2
128K    03.jp2
72K     04.jp2
76K     05.jp2
64K     06.jp2
116K    07.jp2
84K     08.jp2
84K     09.jp2
148K    10.jp2
896K    total

[TestDBThumb]$ du -c *.pgf
76K     01.pgf
56K     02.pgf
132K    03.pgf
80K     04.pgf
76K     05.pgf
68K     06.pgf
104K    07.pgf
88K     08.pgf
88K     09.pgf
124K    10.pgf
892K    total

[TestDBThumb]$ du -c *.png
84K     01.png
60K     02.png
144K    03.png
84K     04.png
96K     05.png
76K     06.png
128K    07.png
108K    08.png
104K    09.png
168K    10.png
1,1M    total

Tests have been performed using 10 different photos from my
collections. Image sizes are 256x256 (a real rectangle with image
data)
PNG files are generated with ImageMagick from bmp reference images.
There is _no_ metadata in PNG (pure image)
This point is important, because with my previous tests, i have use
PNG file generated from JPG with a lots of metadata. For small images,
this is not valid because metadata are large.

Files Generated are :

- JP2 (JPEG2000) in lossless
- PGF in lossless (quality=0)
- JPG with quality = 100 ("-q100" : not lossless but at least the best quallity)
- JPG with quality = 85 ("-q85" : the default value used everywhere
IM, gimp, photoshop, etc.)

JPG quality 85 is the best. Gain = 5
JPG quality 100, PGF and JP2 give the same size. Gain around 1.3.

Of course, we can use PGF and JP2 compression level not lossless. file
size will be decreased, but what will be the gain here against JPG in
this case ?

From speed viewpoint, it's really difficult to measure because a
program need to be written instead to use command line.

To check, i have used a slow computer (my old laptop PIII-600Mhz) and
see from command line which conversion generate target files speedly.
I can see JPG very fast and PGF is a little bit faster than JPEG2000.

All test files are available here, if you want to check visual image
quality : http://digikam3rdparty.free.fr/misc.tarballs/testdbthumbs.tar.bz2

So, JPG sound like the best candidate...

Your viewpoints ?

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> Tests have been performed using 10 different photos from my
> collections. Image sizes are 256x256 (a real rectangle with image
> data)
> PNG files are generated with ImageMagick from bmp reference images.
> There is _no_ metadata in PNG (pure image)
> This point is important, because with my previous tests, i have use
> PNG file generated from JPG with a lots of metadata. For small images,
> this is not valid because metadata are large.
>
> Files Generated are :
>
> - JP2 (JPEG2000) in lossless
> - PGF in lossless (quality=0)
> - JPG with quality = 100 ("-q100" : not lossless but at least the best
> quallity) - JPG with quality = 85 ("-q85" : the default value used
> everywhere IM, gimp, photoshop, etc.)
>
> JPG quality 85 is the best. Gain = 5
> JPG quality 100, PGF and JP2 give the same size. Gain around 1.3.
>
> Of course, we can use PGF and JP2 compression level not lossless. file
> size will be decreased, but what will be the gain here against JPG in
> this case ?

That the main question for me. Why did people bother to write other
compression methods when JPG is available? Usually it's a better file size vs.
quality ratio. Encoding and also decoding performance usually decrease (need
better hardware if time critical) because of more complex algorithms (think of
video: mpeg2 vs. mpeg4 derivatives)

For me as a casual observer the main difference between PGF and JPEG2000 on
the on side and JPEG on the other is the use of discrete wavelet transform vs.
discrete cosine transform. I case of lossless compression the resulted
coefficient are not quantized. In this case the main difference of the formats
cannot be tested, I would not compare JPEG, PGF and JPEG2000 with lossless
compression.
With lossy compression I would expect to have a (measurably) better quality
with wavelet formats than with JPEG at the same file size, or, for us, a
smaller file size for the same measured quality. Alas, I have not the tools to
measure quality and dont trust my subjective impression on this too much, so I
need to believe what is published.
From wikipedia:

"PGF was created to improve upon and replace the JPEG format. It was developed
at the same time as JPEG 2000 but with a different focus: speed over
compression ratio."
=> similar to JPEG 2000, but optimized for speed

"The JPEG 2000 is slightly more space-efficient in the case of natural images.
The PSNR for the same compression ratio is on average 3% better than the PSNR
of PGF.. Its small advantage in compression ratio is paid with a clearly
higher encoding and decoding time."

"The image quality ... for the same compression ratio is on average 3% better
than the PSNR of JPEG. At lower bit rates ... PGF has a much more significant
advantage over certain modes of JPEG: artifacts are less visible and there is
almost no blocking. The compression gains over JPEG are attributed to the use
of DWT."
=> quality: JPEG < PGF < JPEG2000
        speed: JPEG > PGF > JPEG2000
        artifacts: JPEG << PGF, JPEG2000

"The PNG (Portable Network Graphics) format is still more space-efficient in
the case of images with many pixels of the same color. It can be expected that
PNG will be more heavily used for compressing diagram-type images and PGF for
photograph-type images."
=> we are focusing on photos, so PNG is not playing its strengths for us
 

>
> >From speed viewpoint, it's really difficult to measure because a
>
> program need to be written instead to use command line.
>
> To check, i have used a slow computer (my old laptop PIII-600Mhz) and
> see from command line which conversion generate target files speedly.
> I can see JPG very fast and PGF is a little bit faster than JPEG2000.
>
> All test files are available here, if you want to check visual image
> quality : http://digikam3rdparty.free.fr/misc.tarballs/testdbthumbs.tar.bz2
>
> So, JPG sound like the best candidate...
>
> Your viewpoints ?

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

On Tuesday 09 June 2009 14:51:55 Gilles Caulier wrote:

> From speed viewpoint, it's really difficult to measure because a
> program need to be written instead to use command line.
>
> To check, i have used a slow computer (my old laptop PIII-600Mhz) and
> see from command line which conversion generate target files speedly.
> I can see JPG very fast and PGF is a little bit faster than JPEG2000.
>
> All test files are available here, if you want to check visual image
> quality : http://digikam3rdparty.free.fr/misc.tarballs/testdbthumbs.tar.bz2
>
> So, JPG sound like the best candidate...

When scaling image subsampling factor is very important. With default 2x1
(using IM terms) you will get significantly worse results for some images than
with 1x1. Images with 1x1 are slightly bigger but definitely worth it.

You can even lower quality option, combo of q=80 and sf=1x1 will be better
than q=85 sf=2x1.

Another thing worth to think about are thumbnails dimensions. digiKam was tied
with 256 due to .thumbnails standard. On one hand 256 is becoming really small
with new big displays but on the other hand medium sized thumbs are most often
used (also Qt scaling works really good up to 150% of original size of image).

IMatch leaves decision about thumbnails size to user with 200x200 as default.

m.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel