<div dir="ltr"><div>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.</div><div><br></div><div>Tac<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 21, 2020 at 11:24 AM Gilles Caulier <<a href="mailto:caulier.gilles@gmail.com">caulier.gilles@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I post a message to this old thread, as i written a small CLI tool to<br>
convert digiKam PGF blobs stored in database to PNG.<br>
<br>
You can found the code on my github account :<br>
<br>
<a href="https://github.com/cgilles/digikam-pgf-database" rel="noreferrer" target="_blank">https://github.com/cgilles/digikam-pgf-database</a><br>
<br>
Best regards<br>
<br>
Gilles Caulier<br>
<br>
Le ven. 31 janv. 2020 à 10:35, Gilles Caulier<br>
<<a href="mailto:caulier.gilles@gmail.com" target="_blank">caulier.gilles@gmail.com</a>> a écrit :<br>
><br>
><br>
><br>
> Le ven. 31 janv. 2020 à 03:15, Striper <<a href="mailto:barry@bytescience.com" target="_blank">barry@bytescience.com</a>> a écrit :<br>
>><br>
>> Although I understand your arguments and reasoning, I do not fully agree with<br>
>> you. PGF may be the best technical solution for storing thumbnails (or any<br>
>> graphic image for that matter), it's definitely not the best solution from<br>
>> an interoperability standpoint. The simple fact that Google expands its<br>
>> search results for "PGF" with hits on "PDF", means that this format is not<br>
>> widely used nor supported. Except for the C++ implementation on SourceForge<br>
>> (libPGF), there is not a single library or utility to be found that can<br>
>> decode or encode this format. In other words, unless you are developing in<br>
>> C++, it's useless.<br>
>><br>
>> There are countless examples of inferior technology that became the standard<br>
>> over a superior technology (Betamax vs VHS is a classic). For techies like<br>
>> myself, that hurts, but it is a fact of life that we have to live with.<br>
>><br>
>> The great thing about open source is that everybody can use it the way they<br>
>> want to. Digikam is a great product and I love it, but using this kind of<br>
>> exotic formats hampers the "openness", in my opinion. Would anybody really<br>
>> notice the difference in performance or quality when the thumbnails are<br>
>> stored as JPG or PNG? Would a few extra bytes really matter when we are<br>
>> already storing gigabytes of RAW and JPG images?<br>
>><br>
> 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)<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> So to export this code and make a extra project is possible for this function, if somebody is ready to help.<br>
><br>
> Best<br>
><br>
> Gilles Caulier<br>
><br>
</blockquote></div>