<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-07 15:22 GMT+01:00 Juan Jose Casafranca <span dir="ltr"><<a href="mailto:jjcasmar@gmail.com" target="_blank">jjcasmar@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On sábado, 7 de enero de 2017 15:14:09 (CET) Gilles Caulier wrote:<br>
> 2017-01-07 15:08 GMT+01:00 Juan Jose Casafranca <<a href="mailto:jjcasmar@gmail.com">jjcasmar@gmail.com</a>>:<br>
> > On sábado, 7 de enero de 2017 15:03:38 (CET) Gilles Caulier wrote:<br>
> > > As i explain before, ALL thumbnails generated by digiKam are stored in a<br>
> > > dedicated database (sqlite or Mysql).<br>
> > ><br>
> > > The thumbnails are stored using wavelets compression format PGF to<br>
> ><br>
> > optimize<br>
> ><br>
> > > space. In older DK version (3 for ex), we use FreeDesktop way with PNG<br>
> > > which explode storage for huge collection and take a while to store<br>
> > > thumbnails files. Also FreeDesktop recommendations is only limited to<br>
> > > 256x256, which is not enough for Hdpi screen (digiKam can store 512x512<br>
> ><br>
> > and<br>
> ><br>
> > > perhaps more in the future with 8K screen).<br>
> ><br>
> > Okay. But there is no need to change anything in DK for storing<br>
> > thumbnails.<br>
> > The only thing needed is to change the way thumbnails are generated and<br>
> > updated for raw files.<br>
> ><br>
> > Simply, when DK finds a new raw file, instead of loading the embedded jpg<br>
> > file,<br>
> > simply call the raw processor and generate the new file. And when the<br>
> > thumbnail<br>
> > is dirty (as I explained before), regenerate the thumbnail.<br>
><br>
> But this is already the case. We use already a raw decoder named libraw to<br>
> process RAW thumbnails. We will not using another one... Stop to puzzle the<br>
> code<br>
><br>
> Gilles Caulier<br>
<br>
</div></div>So you are telling me that if we want to process a raw file and manage a<br>
library with DK, we have to stay with the simply DK raw processor instead of<br>
using a much more powerful one like darktable? Do you really think that people<br>
out there use the DK raw processor to process their images?<br></blockquote><div><br></div><div>But digiKam is not DarkTable.  The way to mix both cannot be done. This is 2 different applications, one written in Qt other one in GTK...</div><div><br></div><div>The goal currently in DK is to stabilize the code, reduce dependencies, improve port to non Linux. We have plenty of jobs to do, DarkTable is not a priority for the moment.</div><div><br></div><div>Gilles Caulier</div></div></div></div>