[digiKam-users] Thumbnails are in Progessive Graphics File (PGF)

[Tac Tacelosky]

Thanks, Gilles.  If this utility could be incorporated into one of the
widely-available libraries (GD or ImageMagick), then the conversion could
be done on the fly.  Or if the user had the option of configuring the
database to store an additional data blob as a png or jpeg, with
appropriate configuration data, then the database itself could provide the
images.  This would open up the data to developers who know how to access
the database, even without C experience.

Tac

On Thu, May 21, 2020 at 11:24 AM Gilles Caulier <caulier.gilles at gmail.com>
wrote:

> Hi,
>
> I post a message to this old thread, as i written a small CLI tool to
> convert digiKam PGF blobs stored in database to PNG.
>
> You can found the code on my github account :
>
> https://github.com/cgilles/digikam-pgf-database
>
> Best regards
>
> Gilles Caulier
>
> Le ven. 31 janv. 2020 à 10:35, Gilles Caulier
> <caulier.gilles at gmail.com> a écrit :
> >
> >
> >
> > Le ven. 31 janv. 2020 à 03:15, Striper <barry at bytescience.com> a écrit :
> >>
> >> Although I understand your arguments and reasoning, I do not fully
> agree with
> >> you. PGF may be the best technical solution for storing thumbnails (or
> any
> >> graphic image for that matter), it's definitely not the best solution
> from
> >> an interoperability standpoint. The simple fact that Google expands its
> >> search results for "PGF" with hits on "PDF", means that this format is
> not
> >> widely used nor supported. Except for the C++ implementation on
> SourceForge
> >> (libPGF), there is not a single library or utility to be found that can
> >> decode or encode this format. In other words, unless you are developing
> in
> >> C++, it's useless.
> >>
> >> There are countless examples of inferior technology that became the
> standard
> >> over a superior technology (Betamax vs VHS is a classic). For techies
> like
> >> myself, that hurts, but it is a fact of life that we have to live with.
> >>
> >> The great thing about open source is that everybody can use it the way
> they
> >> want to. Digikam is a great product and I love it, but using this kind
> of
> >> exotic formats hampers the "openness", in my opinion. Would anybody
> really
> >> notice the difference in performance or quality when the thumbnails are
> >> stored as JPG or PNG? Would a few extra bytes really matter when we are
> >> already storing gigabytes of RAW and JPG images?
> >>
> > PGF is so far interresting in regard of thumbnails storage in the
> database. It use wavelets algorithm which compress better than JPG and of
> course all other image format (PNG, TIFF RAW)
> >
> > Algorithm is also very optimized : faster and quality. Using JPEG for
> thumbnails storage is not the best choice, even is compressing time is
> mostly the same.
> >
> > Writing a small CLI tool to extract PGF from database and export to JPEG
> already exists in digiKam unit tests. Remember that libpgf source code is
> embedded in digiKam core.
> >
> > So to export this code and make a extra project is possible for this
> function, if somebody is ready to help.
> >
> > Best
> >
> > Gilles Caulier
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20200521/54722088/attachment.htm>