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

[Gilles Caulier-4]

Le ven. 31 janv. 2020 à 03:15, Striper <[hidden email]> 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

[Gilles Caulier-4]

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
<[hidden email]> a écrit :

>
>
>
> Le ven. 31 janv. 2020 à 03:15, Striper <[hidden email]> 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
>

[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 <[hidden email]> 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
<[hidden email]> a écrit :
>
>
>
> Le ven. 31 janv. 2020 à 03:15, Striper <[hidden email]> 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
>