<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-07 16:22 GMT+01:00 Gilles Caulier <span dir="ltr"><<a href="mailto:caulier.gilles@gmail.com" target="_blank">caulier.gilles@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">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="m_2970993905226860942gmail-HOEnZb"><div class="m_2970993905226860942gmail-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" target="_blank">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" target="_blank">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></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></div></div></div></blockquote><div><br></div><div>I'm not asking to change the raw processor. Just asking to allow the user which raw processor wants to use. If the user selects to use DT, simply make him enter the DT executable which will be called when the raw file must be processed. No dependency needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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></span><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><span class="HOEnZb"><font color="#888888"><div><br></div><div>Gilles Caulier</div></font></span></div></div></div>
</blockquote></div><br></div></div>