extragear/graphics/digikam/digikam

[Gilles Caulier-4]

2009/6/13 Mikolaj Machowski <[hidden email]>:

> On Friday 12 June 2009 21:07:26 Gilles Caulier wrote:
>
>> > Used this for my files (15,000):
>> >
>> > 1) size of database: 243 MB, size of .thumbnails/large: 1.3GB
>> > 2) creation time - for me recreation of all thumbnails takes so long that
>> > I have to do other things in meantime so it is incomparable (and data
>> > useless) but just for interest it was cut 20% - and "live" creation of
>> > thumbs (displaying them with empty database) was faster for me than
>> > previously 3) what for me is most important - time of display of images
>> > which thumbs are already in database: unfortunately there is scientific
>> > method, just feelings - maybe bit faster, definitely not slower
>> > 4) quality of images (used default PGF, q=4, don't know how to switch to
>> > JPG):
>>
>> To switch to JPG, it's easy :
>>
>> http://lxr.kde.org/source/extragear/graphics/digikam/libs/threadimageio/thu
>>mbnailcreator.cpp#481
>>
>> Change this line to dbInfo.type = DatabaseThumbnail::JPEG;
>>
>> recompile, install. Remove your thumbs database file and start digiKam
>> again....
>
> OK. First note: no way default JPEG comression for Qt is 85. Compiled only
> with your change and JPEG artefacts were visible in many images. Size of
> database was 142MB. Creation time comparable with PGF version, but quality
> much lower.
>
> Tested again with declaring 85 in
>
> http://lxr.kde.org/source/extragear/graphics/digikam/libs/threadimageio/thumbnailcreator.cpp#498
>
> And quality was much better with database size of 184MB and again roughly the
> same time of creation and quality similar to PGF version. However JPEG based
> db is much more resources intensive, eg. playing movies wasn't fluent while I
> was able to view them comfortably while creating PGF db. Quality slightly
> lower comparing to PGF but not dramatically. Time of display comparable. Pity
> you cannot change chroma subsampling when making JPEGs directly in Qt :(

Marcel, do you see this comment from Mik about JPEG and PGF performance  ?

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

On Saturday 13 June 2009 17:17:37 Gilles Caulier wrote:

> 2009/6/13 Marcel Wiesweg <[hidden email]>:
> >> Result are better than PGF, from speed and space consumption point...
> >
> > For me results with JPEG are better as well.
> > I have an average size of 11KB per thumbnail (db file size / number of
> > stored thumbnails).
> > Most important for me: Subjectively, loading is faster than with PGF.
> > (With maximum number of icons visible - no sidebars, fullscreen, minimum
> > thumbnail size - I can mouse wheel scroll at a reasonable fast speed
> > without seeing missing thumbnails)
>
> Well, what better then ? JPEG as well with a compression ratio upper
> than 75 (default Qt = 75) ? I recommend 85 instead...
>
> Mik, do you have tried 85 JPEG quality ? And in this case, DB will be
> bigger : which size compared to PGF ?

JPEG Qt default (probably 75): 147MB for 15000 images
JPEG 85: 184MB
PGF 4: 243MB

>
> > For me creation time is not important, because this is done once, but
> > pregenerated thumbnail loading time, which is done everytime.
>
> Agree but it give info about algorithm optimization. For ex, JPEG2000
> is a mess in this case...
>
> I'm in contact with libPGF team. I will ask speed optimization
> question comparing to JPEG.
>

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

[Gilles Caulier-4]

2009/6/13 Mikolaj Machowski <[hidden email]>:

> On Saturday 13 June 2009 17:17:37 Gilles Caulier wrote:
>> 2009/6/13 Marcel Wiesweg <[hidden email]>:
>> >> Result are better than PGF, from speed and space consumption point...
>> >
>> > For me results with JPEG are better as well.
>> > I have an average size of 11KB per thumbnail (db file size / number of
>> > stored thumbnails).
>> > Most important for me: Subjectively, loading is faster than with PGF.
>> > (With maximum number of icons visible - no sidebars, fullscreen, minimum
>> > thumbnail size - I can mouse wheel scroll at a reasonable fast speed
>> > without seeing missing thumbnails)
>>
>> Well, what better then ? JPEG as well with a compression ratio upper
>> than 75 (default Qt = 75) ? I recommend 85 instead...
>>
>> Mik, do you have tried 85 JPEG quality ? And in this case, DB will be
>> bigger : which size compared to PGF ?
>
> JPEG Qt default (probably 75): 147MB for 15000 images
> JPEG 85: 184MB
> PGF 4: 243MB

Thanks Mik,

And now, time mesurement. Not easy to do because PC timer is not fine...

in digikam/test, i just patched qtpgftest program to measure execusion
of encoding decoding PGF and JPEG image to/from byte array with same
DB conditions. Look result with small test.png image :

[gilles@localhost tests]$ identify test.png
test.png PNG 256x256 256x256+0+0 8-bit DirectClass 168kb

[gilles@localhost tests]$ ./qtpgftest.shell
<unknown program name>(6778)/ main: PGF Encoding time:  0.05  s
<unknown program name>(6778)/ main: PGF Decoding time:  0.03  s
<unknown program name>(6778)/ main: JPG Encoding time:  0.01  s
<unknown program name>(6778)/ main: JPG Decoding time:  0.01  s

If i retry test many time, with other image files, i can always see
JPG faster... JPEG compression is 85

Now, if i take a large image to test (a raw image converted to png):

[gilles@localhost tests]$ identify test.png
test.png PNG 3594x2397 3594x2397+0+0 16-bit DirectClass 24.58mb

[gilles@localhost tests]$ ./qtpgftest.shell
<unknown program name>(7467)/ main: PGF Encoding time:  3.61  s
<unknown program name>(7467)/ main: PGF Decoding time:  2.65  s
<unknown program name>(7467)/ main: JPG Encoding time:  0.66  s
<unknown program name>(7467)/ main: JPG Decoding time:  0.6  s

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

[Gilles Caulier-4]

2009/6/14 Gilles Caulier <[hidden email]>:

> 2009/6/13 Mikolaj Machowski <[hidden email]>:
>> On Saturday 13 June 2009 17:17:37 Gilles Caulier wrote:
>>> 2009/6/13 Marcel Wiesweg <[hidden email]>:
>>> >> Result are better than PGF, from speed and space consumption point...
>>> >
>>> > For me results with JPEG are better as well.
>>> > I have an average size of 11KB per thumbnail (db file size / number of
>>> > stored thumbnails).
>>> > Most important for me: Subjectively, loading is faster than with PGF.
>>> > (With maximum number of icons visible - no sidebars, fullscreen, minimum
>>> > thumbnail size - I can mouse wheel scroll at a reasonable fast speed
>>> > without seeing missing thumbnails)
>>>
>>> Well, what better then ? JPEG as well with a compression ratio upper
>>> than 75 (default Qt = 75) ? I recommend 85 instead...
>>>
>>> Mik, do you have tried 85 JPEG quality ? And in this case, DB will be
>>> bigger : which size compared to PGF ?
>>
>> JPEG Qt default (probably 75): 147MB for 15000 images
>> JPEG 85: 184MB
>> PGF 4: 243MB
>
>
> Thanks Mik,
>
> And now, time mesurement. Not easy to do because PC timer is not fine...
>
> in digikam/test, i just patched qtpgftest program to measure execusion
> of encoding decoding PGF and JPEG image to/from byte array with same
> DB conditions. Look result with small test.png image :
>
> [gilles@localhost tests]$ identify test.png
> test.png PNG 256x256 256x256+0+0 8-bit DirectClass 168kb
>
> [gilles@localhost tests]$ ./qtpgftest.shell
> <unknown program name>(6778)/ main: PGF Encoding time:  0.05  s
> <unknown program name>(6778)/ main: PGF Decoding time:  0.03  s
> <unknown program name>(6778)/ main: JPG Encoding time:  0.01  s
> <unknown program name>(6778)/ main: JPG Decoding time:  0.01  s
>
> If i retry test many time, with other image files, i can always see
> JPG faster... JPEG compression is 85
>
> Now, if i take a large image to test (a raw image converted to png):
>
> [gilles@localhost tests]$ identify test.png
> test.png PNG 3594x2397 3594x2397+0+0 16-bit DirectClass 24.58mb
>
> [gilles@localhost tests]$ ./qtpgftest.shell
> <unknown program name>(7467)/ main: PGF Encoding time:  3.61  s
> <unknown program name>(7467)/ main: PGF Decoding time:  2.65  s
> <unknown program name>(7467)/ main: JPG Encoding time:  0.66  s
> <unknown program name>(7467)/ main: JPG Decoding time:  0.6  s
>
> Gilles Caulier
>

Important :

libpgf is compiled in digiKam with full debug symbols : no optimizations.

JPEG codec come from QT4 with debug symbol an certainly full optimizations.

I will recompile digiKam with optimizations options to see the difference.

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

[Gilles Caulier-4]

2009/6/14 Gilles Caulier <[hidden email]>:

> 2009/6/14 Gilles Caulier <[hidden email]>:
>> 2009/6/13 Mikolaj Machowski <[hidden email]>:
>>> On Saturday 13 June 2009 17:17:37 Gilles Caulier wrote:
>>>> 2009/6/13 Marcel Wiesweg <[hidden email]>:
>>>> >> Result are better than PGF, from speed and space consumption point...
>>>> >
>>>> > For me results with JPEG are better as well.
>>>> > I have an average size of 11KB per thumbnail (db file size / number of
>>>> > stored thumbnails).
>>>> > Most important for me: Subjectively, loading is faster than with PGF.
>>>> > (With maximum number of icons visible - no sidebars, fullscreen, minimum
>>>> > thumbnail size - I can mouse wheel scroll at a reasonable fast speed
>>>> > without seeing missing thumbnails)
>>>>
>>>> Well, what better then ? JPEG as well with a compression ratio upper
>>>> than 75 (default Qt = 75) ? I recommend 85 instead...
>>>>
>>>> Mik, do you have tried 85 JPEG quality ? And in this case, DB will be
>>>> bigger : which size compared to PGF ?
>>>
>>> JPEG Qt default (probably 75): 147MB for 15000 images
>>> JPEG 85: 184MB
>>> PGF 4: 243MB
>>
>>
>> Thanks Mik,
>>
>> And now, time mesurement. Not easy to do because PC timer is not fine...
>>
>> in digikam/test, i just patched qtpgftest program to measure execusion
>> of encoding decoding PGF and JPEG image to/from byte array with same
>> DB conditions. Look result with small test.png image :
>>
>> [gilles@localhost tests]$ identify test.png
>> test.png PNG 256x256 256x256+0+0 8-bit DirectClass 168kb
>>
>> [gilles@localhost tests]$ ./qtpgftest.shell
>> <unknown program name>(6778)/ main: PGF Encoding time:  0.05  s
>> <unknown program name>(6778)/ main: PGF Decoding time:  0.03  s
>> <unknown program name>(6778)/ main: JPG Encoding time:  0.01  s
>> <unknown program name>(6778)/ main: JPG Decoding time:  0.01  s
>>
>> If i retry test many time, with other image files, i can always see
>> JPG faster... JPEG compression is 85
>>
>> Now, if i take a large image to test (a raw image converted to png):
>>
>> [gilles@localhost tests]$ identify test.png
>> test.png PNG 3594x2397 3594x2397+0+0 16-bit DirectClass 24.58mb
>>
>> [gilles@localhost tests]$ ./qtpgftest.shell
>> <unknown program name>(7467)/ main: PGF Encoding time:  3.61  s
>> <unknown program name>(7467)/ main: PGF Decoding time:  2.65  s
>> <unknown program name>(7467)/ main: JPG Encoding time:  0.66  s
>> <unknown program name>(7467)/ main: JPG Decoding time:  0.6  s
>>

Look time measurements with release mode (same image) :

[gilles@localhost tests]$ ./qtpgftest.shell
PGF Encoding time:  1.91  s
PGF Decoding time:  1.29  s
JPG Encoding time:  0.66  s
JPG Decoding time:  0.6  s

PGF is better but JPEG is always better...

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

I always compile digiKam with "debug" instead "debugfull", according to this
page the only difference is that code is optimized:
http://techbase.kde.org/Development/CMake/Build_Types

Do I have any advantages when choosing "debugfull"?
When I use callgrind for example, it is always better to run with
optimizations turned on.

Andi

On Sunday 14 June 2009 08:56:09 Gilles Caulier wrote:

> 2009/6/14 Gilles Caulier <[hidden email]>:
> > 2009/6/13 Mikolaj Machowski <[hidden email]>:
> >> On Saturday 13 June 2009 17:17:37 Gilles Caulier wrote:
> >>> 2009/6/13 Marcel Wiesweg <[hidden email]>:
> >>> >> Result are better than PGF, from speed and space consumption
> >>> >> point...
> >>> >
> >>> > For me results with JPEG are better as well.
> >>> > I have an average size of 11KB per thumbnail (db file size / number
> >>> > of stored thumbnails).
> >>> > Most important for me: Subjectively, loading is faster than with PGF.
> >>> > (With maximum number of icons visible - no sidebars, fullscreen,
> >>> > minimum thumbnail size - I can mouse wheel scroll at a reasonable
> >>> > fast speed without seeing missing thumbnails)
> >>>
> >>> Well, what better then ? JPEG as well with a compression ratio upper
> >>> than 75 (default Qt = 75) ? I recommend 85 instead...
> >>>
> >>> Mik, do you have tried 85 JPEG quality ? And in this case, DB will be
> >>> bigger : which size compared to PGF ?
> >>
> >> JPEG Qt default (probably 75): 147MB for 15000 images
> >> JPEG 85: 184MB
> >> PGF 4: 243MB
> >
> > Thanks Mik,
> >
> > And now, time mesurement. Not easy to do because PC timer is not fine...
> >
> > in digikam/test, i just patched qtpgftest program to measure execusion
> > of encoding decoding PGF and JPEG image to/from byte array with same
> > DB conditions. Look result with small test.png image :
> >
> > [gilles@localhost tests]$ identify test.png
> > test.png PNG 256x256 256x256+0+0 8-bit DirectClass 168kb
> >
> > [gilles@localhost tests]$ ./qtpgftest.shell
> > <unknown program name>(6778)/ main: PGF Encoding time:  0.05  s
> > <unknown program name>(6778)/ main: PGF Decoding time:  0.03  s
> > <unknown program name>(6778)/ main: JPG Encoding time:  0.01  s
> > <unknown program name>(6778)/ main: JPG Decoding time:  0.01  s
> >
> > If i retry test many time, with other image files, i can always see
> > JPG faster... JPEG compression is 85
> >
> > Now, if i take a large image to test (a raw image converted to png):
> >
> > [gilles@localhost tests]$ identify test.png
> > test.png PNG 3594x2397 3594x2397+0+0 16-bit DirectClass 24.58mb
> >
> > [gilles@localhost tests]$ ./qtpgftest.shell
> > <unknown program name>(7467)/ main: PGF Encoding time:  3.61  s
> > <unknown program name>(7467)/ main: PGF Decoding time:  2.65  s
> > <unknown program name>(7467)/ main: JPG Encoding time:  0.66  s
> > <unknown program name>(7467)/ main: JPG Decoding time:  0.6  s
> >
> > Gilles Caulier
>
> Important :
>
> libpgf is compiled in digiKam with full debug symbols : no optimizations.
>
> JPEG codec come from QT4 with debug symbol an certainly full optimizations.
>
> I will recompile digiKam with optimizations options to see the difference.
>
> Gilles Caulier
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

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

[Gilles Caulier-4]

2009/6/13 Marcel Wiesweg <[hidden email]>:
>
>> Result are better than PGF, from speed and space consumption point...
>>
>
> For me results with JPEG are better as well.

For me, as Mik said, JPEG give artifact on thumbs, with 256x256 size,
especially with image which have geometric forms (wall, houses,
momuments) or high subject contrast as flowers taken in macro mode and
with large zone with same colors ( it's not visible with complex
images composition with high levels of details) . Sound like
anti-aliasing is not visible.

I tried 90 compression instead 85, but it still visible.

I cannot see this problem with PGF...

Gilles

> I have an average size of 11KB per thumbnail (db file size / number of stored
> thumbnails).
> Most important for me: Subjectively, loading is faster than with PGF. (With
> maximum number of icons visible - no sidebars, fullscreen, minimum thumbnail
> size - I can mouse wheel scroll at a reasonable fast speed without seeing
> missing thumbnails)
>
> For me creation time is not important, because this is done once, but
> pregenerated thumbnail loading time, which is done everytime.
>
> Btw, once all thumbnails are built, because of the shortcomings that Andi
> mentioned, it is a benchmark of pregenerated thumbnail loading when running
> the "Rebuild Thumbnail -> Scan" dialog - it will load all existing thumbnails.
>
> Marcel
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>

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

[Marcel Wiesweg]

> Look time measurements with release mode (same image) :
>
> [gilles@localhost tests]$ ./qtpgftest.shell
> PGF Encoding time:  1.91  s
> PGF Decoding time:  1.29  s
> JPG Encoding time:  0.66  s
> JPG Decoding time:  0.6  s
>
> PGF is better but JPEG is always better...
>

Your result correlate quite well with my subjective impression.

I dont care quite so much if a JPEG with quality 90 is larger than with 75 -
compared to the freedesktop standard's PNGs it is still much smaller.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> 2009/6/13 Marcel Wiesweg <[hidden email]>:
> >> Result are better than PGF, from speed and space consumption point...
> >
> > For me results with JPEG are better as well.
>
> For me, as Mik said, JPEG give artifact on thumbs, with 256x256 size,
> especially with image which have geometric forms (wall, houses,
> momuments) or high subject contrast as flowers taken in macro mode and
> with large zone with same colors ( it's not visible with complex
> images composition with high levels of details) . Sound like
> anti-aliasing is not visible.
>
> I tried 90 compression instead 85, but it still visible.
>
> I cannot see this problem with PGF...

I see this dilemma:

PGF: quality good, file size good, speed bad + + -
JPEG: quality bad, file size good, speed good - + +
PNG: quality good, file size bad, speed good + - +

(JPEG2000 has the same properties in this listing as PGF but is slower, so I
left it out)

It's pretty normal in life that you can't get everything you want, and here it
seems we need to decide to sacrifice either quality, disk space or speed.

Marcel

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

Well in this case I wouldn't drop speed... it really keeps users away from
digiKam if it feels like running on an old 486 or PII PC.

Andi

On Sunday 14 June 2009 18:45:26 Marcel Wiesweg wrote:

> > 2009/6/13 Marcel Wiesweg <[hidden email]>:
> > >> Result are better than PGF, from speed and space consumption point...
> > >
> > > For me results with JPEG are better as well.
> >
> > For me, as Mik said, JPEG give artifact on thumbs, with 256x256 size,
> > especially with image which have geometric forms (wall, houses,
> > momuments) or high subject contrast as flowers taken in macro mode and
> > with large zone with same colors ( it's not visible with complex
> > images composition with high levels of details) . Sound like
> > anti-aliasing is not visible.
> >
> > I tried 90 compression instead 85, but it still visible.
> >
> > I cannot see this problem with PGF...
>
> I see this dilemma:
>
> PGF: quality good, file size good, speed bad + + -
> JPEG: quality bad, file size good, speed good - + +
> PNG: quality good, file size bad, speed good + - +
>
> (JPEG2000 has the same properties in this listing as PGF but is slower, so
> I left it out)
>
> It's pretty normal in life that you can't get everything you want, and here
> it seems we need to decide to sacrifice either quality, disk space or
> speed.
>
> Marcel
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

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

[Gilles Caulier-4]

2009/6/14 Marcel Wiesweg <[hidden email]>:

>> 2009/6/13 Marcel Wiesweg <[hidden email]>:
>> >> Result are better than PGF, from speed and space consumption point...
>> >
>> > For me results with JPEG are better as well.
>>
>> For me, as Mik said, JPEG give artifact on thumbs, with 256x256 size,
>> especially with image which have geometric forms (wall, houses,
>> momuments) or high subject contrast as flowers taken in macro mode and
>> with large zone with same colors ( it's not visible with complex
>> images composition with high levels of details) . Sound like
>> anti-aliasing is not visible.
>>
>> I tried 90 compression instead 85, but it still visible.
>>
>> I cannot see this problem with PGF...
>
> I see this dilemma:
>
> PGF: quality good, file size good, speed bad            + + -
> JPEG: quality bad, file size good, speed good   - + +
> PNG: quality good, file size bad, speed good    + - +
>
> (JPEG2000 has the same properties in this listing as PGF but is slower, so I
> left it out)

and JPEG2000 iostream for QImage implemented to kdeimgio do not work...

>
> It's pretty normal in life that you can't get everything you want, and here it
> seems we need to decide to sacrifice either quality, disk space or speed.


Ah ah... and now i found another point con JPEG : alpha channel :

PGF : ok
PNG : ok
JPEG : no.

Note : JPEG2000 : ok

well, JPEG no not support alpha chanel... If you try to display  a
thumb from an image with alpha, this channel will be replaced by white
(if i'm not too wrong). I remember an old B.K.O entry about a dumy bug
in the past....

We need to support alpha chanel. No way.

To wrap around JPEG, there is a solution : JNG. What's is that ? It's
PNG file container using JPEG compression and alpha support :

http://en.wikipedia.org/wiki/JPEG_Network_Graphics

Problem : there is no Qt4 support for JNG :

http://doc.trolltech.com/4.5/qimagewriter.html#supportedImageFormats

...and kimgio do not have a plugin for that...

So for me, PGF is the only alternative...

Gilles


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

Hmm why do we need alpha channel support? Never seen a photo with an alpha
channel :D

Well anyway I can't say what I prefer, I can only say that with big
collections (and we must check this, because this might become quickly an
issue) the thumbsDB is awfully slow.
And I don't think any file format will save us from this, because it is sqlite
that is not good performing here.

Andi

On Sunday 14 June 2009 20:53:14 Gilles Caulier wrote:

> 2009/6/14 Marcel Wiesweg <[hidden email]>:
> >> 2009/6/13 Marcel Wiesweg <[hidden email]>:
> >> >> Result are better than PGF, from speed and space consumption point...
> >> >
> >> > For me results with JPEG are better as well.
> >>
> >> For me, as Mik said, JPEG give artifact on thumbs, with 256x256 size,
> >> especially with image which have geometric forms (wall, houses,
> >> momuments) or high subject contrast as flowers taken in macro mode and
> >> with large zone with same colors ( it's not visible with complex
> >> images composition with high levels of details) . Sound like
> >> anti-aliasing is not visible.
> >>
> >> I tried 90 compression instead 85, but it still visible.
> >>
> >> I cannot see this problem with PGF...
> >
> > I see this dilemma:
> >
> > PGF: quality good, file size good, speed bad            + + -
> > JPEG: quality bad, file size good, speed good   - + +
> > PNG: quality good, file size bad, speed good    + - +
> >
> > (JPEG2000 has the same properties in this listing as PGF but is slower,
> > so I left it out)
>
> and JPEG2000 iostream for QImage implemented to kdeimgio do not work...
>
> > It's pretty normal in life that you can't get everything you want, and
> > here it seems we need to decide to sacrifice either quality, disk space
> > or speed.
>
> Ah ah... and now i found another point con JPEG : alpha channel :
>
> PGF : ok
> PNG : ok
> JPEG : no.
>
> Note : JPEG2000 : ok
>
> well, JPEG no not support alpha chanel... If you try to display  a
> thumb from an image with alpha, this channel will be replaced by white
> (if i'm not too wrong). I remember an old B.K.O entry about a dumy bug
> in the past....
>
> We need to support alpha chanel. No way.
>
> To wrap around JPEG, there is a solution : JNG. What's is that ? It's
> PNG file container using JPEG compression and alpha support :
>
> http://en.wikipedia.org/wiki/JPEG_Network_Graphics
>
> Problem : there is no Qt4 support for JNG :
>
> http://doc.trolltech.com/4.5/qimagewriter.html#supportedImageFormats
>
> ...and kimgio do not have a plugin for that...
>
> So for me, PGF is the only alternative...
>
> Gilles
>
> > Marcel
> >
> > _______________________________________________
> > Digikam-devel mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-devel
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

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

[Gilles Caulier-4]

2009/6/14 Gilles Caulier <[hidden email]>:

> 2009/6/14 Marcel Wiesweg <[hidden email]>:
>>> 2009/6/13 Marcel Wiesweg <[hidden email]>:
>>> >> Result are better than PGF, from speed and space consumption point...
>>> >
>>> > For me results with JPEG are better as well.
>>>
>>> For me, as Mik said, JPEG give artifact on thumbs, with 256x256 size,
>>> especially with image which have geometric forms (wall, houses,
>>> momuments) or high subject contrast as flowers taken in macro mode and
>>> with large zone with same colors ( it's not visible with complex
>>> images composition with high levels of details) . Sound like
>>> anti-aliasing is not visible.
>>>
>>> I tried 90 compression instead 85, but it still visible.
>>>
>>> I cannot see this problem with PGF...
>>
>> I see this dilemma:
>>
>> PGF: quality good, file size good, speed bad            + + -

For PGF, i'm in contact with libpgf team. i will ask if
encoding/decoding performance still possible for the future....

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

[Gilles Caulier-4]

2009/6/14 Andi Clemens <[hidden email]>:
> Hmm why do we need alpha channel support? Never seen a photo with an alpha
> channel :D

You cannot limit digiKam to photo. I know a lots of users playing in
digital arts who use digiKam to manage GIF, PNG, TIFF files with alpha
channel dedicated for the web

>
> Well anyway I can't say what I prefer, I can only say that with big
> collections (and we must check this, because this might become quickly an
> issue) the thumbsDB is awfully slow.
> And I don't think any file format will save us from this, because it is sqlite
> that is not good performing here.

agree. sqlite interface need to be improved...

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

On Sunday 14 June 2009 14:35:42 Gilles Caulier wrote:

> 2009/6/13 Marcel Wiesweg <[hidden email]>:
> >> Result are better than PGF, from speed and space consumption point...
> >
> > For me results with JPEG are better as well.
>
> For me, as Mik said, JPEG give artifact on thumbs, with 256x256 size,
> especially with image which have geometric forms (wall, houses,
> momuments) or high subject contrast as flowers taken in macro mode and
> with large zone with same colors ( it's not visible with complex
> images composition with high levels of details) . Sound like
> anti-aliasing is not visible.
>
> I tried 90 compression instead 85, but it still visible.

Gilles, for artifacts and quality of image in rescaling more important than 5
points is chroma sampling. Bare Qt uses 2x1x1 or worse. To improve quality of
JPEGs digiKam should use its own processes which can use highest possible
sampling of 1x1x1.

Just for information - my collection of 15000:
226M    thumbnails-digikam.db     <- JPEG q=90
184M    thumbnails-digikam-jpeg.db <- JPEG q=85
243M    thumbnails-digikam-pgf.db <- PGF

About database: did you consider mysqld? Due to Amarok it should be available
without problems on most Linux desktop systems.

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