<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-07 15:41 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On sábado, 7 de enero de 2017 15:25:43 (CET) Gilles Caulier wrote:<br>
> 2017-01-07 15:22 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: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<br>
> ><br>
> > in a<br>
> ><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<br>
> ><br>
> > PNG<br>
> ><br>
> > > > > which explode storage for huge collection and take a while to store<br>
> > > > > thumbnails files. Also FreeDesktop recommendations is only limited<br>
> > > > > to<br>
> > > > > 256x256, which is not enough for Hdpi screen (digiKam can store<br>
> ><br>
> > 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<br>
> > > > and<br>
> > > > updated for raw files.<br>
> > > ><br>
> > > > Simply, when DK finds a new raw file, instead of loading the embedded<br>
> ><br>
> > jpg<br>
> ><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<br>
> ><br>
> > to<br>
> ><br>
> > > process RAW thumbnails. We will not using another one... Stop to puzzle<br>
> ><br>
> > the<br>
> ><br>
> > > code<br>
> > ><br>
> > > Gilles Caulier<br>
> ><br>
> > 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<br>
> > of<br>
> > using a much more powerful one like darktable? Do you really think that<br>
> > people<br>
> > out there use the DK raw processor to process their images?<br>
><br>
> But digiKam is not DarkTable.  The way to mix both cannot be done. This is<br>
> 2 different applications, one written in Qt other one in GTK...<br>
><br>
> The goal currently in DK is to stabilize the code, reduce dependencies,<br>
> improve port to non Linux. We have plenty of jobs to do, DarkTable is not a<br>
> priority for the moment.<br>
><br>
> Gilles Caulier<br>
<br>
</div></div>I know that they are two different apps. I dont understand why GTK and Qt is<br>
even a question here. I'm not saying to add DT as a depency for DK, just let<br>
the user decide which raw processor uses.<br></blockquote><div><br></div><div>But Raw processor from DT is not the same than DK as i know. Changing Raw processor in digiKam by DT one is as to add DT dependencies to DK.  No way here...</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As I said, I can try to develop this by myself, I'm not asking any dedicated<br>
DK developer to do it... What I only need is a little guideline on how the<br>
thumbnails are generated, how they are stored in the database and some other<br>
stuff for letting the user choose which processor wants to choose.<br></blockquote><div><br></div><div>2 possibilities :</div><div><br></div><div>1/ use DBus to ping digiKam core about thumbnails changed externally. Only Linux solution. </div><div><br></div><div>2/ use XMP sidecar to store a local path to new thumbnails processed into DT XMP namespace. I don't like this too much by at least it store the minimum to XMP.</div><div><br></div><div>3/ store wavelets compressed preview in XMP sidecar to Iptc.Application2.Preview</div><div><br></div><div>4/ use a thumbnail sidecar file near RAW file as .thumb. I see this solution already used under Windows, but i don't remember which application exactly. I know that Canon camera do it also. It's a simple JPEG file with metadata This way will duplicata data of course.</div><div><br></div><div>Gilles Caulier</div></div></div></div>