<div dir="ltr">As i explain before, ALL thumbnails generated by digiKam are stored in a dedicated database (sqlite or Mysql).<div><br></div><div>The thumbnails are stored using wavelets compression format PGF to optimize space. In older DK version (3 for ex), we use FreeDesktop way with PNG which explode storage for huge collection and take a while to store thumbnails files. Also FreeDesktop recommendations is only limited to 256x256, which is not enough for Hdpi screen (digiKam can store 512x512 and perhaps more in the future with 8K screen).</div><div><br></div><div>So, no way to change something in DK to store thumbnails for the moment.</div><div><br></div><div>Gilles Caulier</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-07 14: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: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 13:51:57 (CET) Gilles Caulier wrote:<br>
> 2017-01-07 12:51 GMT+01:00 Juan Jose Casafranca <<a href="mailto:jjcasmar@gmail.com">jjcasmar@gmail.com</a>>:<br>
> > I think you are trying to solve the problem in a very complex way.<br>
> ><br>
> > First of all, where does digikam currently saves the thumbnails? If it's<br>
> > in<br>
> > the database, then, the only thing needed is a way to generate the<br>
> > processed<br>
> > raw as a thumbnail and a flag which specify if the thumbnail is up to<br>
> > date.<br>
> ><br>
> > This flag es very easy to maintain. When loading the database, the<br>
> > thumbnails<br>
> > are not up to date. So darktable (or any other raw processor) will be<br>
> > called<br>
> > to generate the thumbnails. When a raw file is opened for edition through<br>
> > the<br>
> > digikam interface, then also mark the thumbnail is not up to date. If the<br>
> > user<br>
> > opens the file for edition from other place different from the digikam<br>
> > interface (opening the raw processor directly for example), then do<br>
> > anything.<br>
> > I know that thumbnail stored and the processed image will not match in<br>
> > this<br>
> > case, this should be documented. Enable an option to update manually the<br>
> > thumbnails for raw files.<br>
> ><br>
> > Digikam should have an option to choose which raw processor want the user<br>
> > to<br>
> > user. Default one, darktable, raw therapee, whatever. When a user try to<br>
> > edits<br>
> > a raw file, then the raw processor selected is opened.<br>
> ><br>
> > I dont think that we need to store any extra information in the xmp file.<br>
> > Simply, made different software dont override other software xmp tags (as<br>
> > I<br>
> > said in other post, I think this is common sense).<br>
> ><br>
> > Digikam would not treat darktable in a special way. I'm just asking for an<br>
> > interface to connect digikam with any raw processor. This interface should<br>
> > only need to provide a way to open the raw processor with the selected<br>
> > image<br>
> > and a way to get back the image from the raw processor.<br>
> ><br>
> > I dont really understand why digikam and raw processors should communicate<br>
> > through the xmp file.<br>
> ><br>
> > So, to summarize:<br>
> > User selects darktable for raw editing<br>
><br>
> Already possible in Linux desktop, through OpenWith context menu.<br>
><br>
> > User opens a raw file in digikam -> darktable is opened<br>
><br>
> Already possible in Linux Desktop, with default application set in desktop,<br>
> that can be handle through a keyboard shortcut. I introduced myself in<br>
> 5.0.0. Perhaps this need to be improved, but a good desktop settings in a<br>
> best start.<br>
><br>
> > User edits in darktable and close it -> thumbnail is marked as not up to<br>
> > date<br>
> > Thumbnail is updated calling darktable which returns an image (maybe with<br>
> > a<br>
> > LUA script?)<br>
><br>
> DBUS can be used here. It's easy, but... This will only work under Linux.<br>
> Forget MacOS and Windows, DBUS is a waste of time.<br>
<br>
</div></div>What do you propose for windows and mac? Or just implement this as a linux<br>
only feature? (Anyway, windows and mac users already has another raw<br>
processing workflow which includes other software, dont they?)<br>
<span class=""><br>
><br>
> > The thumbnail is stored in digikam the same way other jpeg or current raw<br>
> > thumbnails are stored<br>
><br>
> On this point, i'm not agree. It"s a regression and an user wish fixed few<br>
> year ago...<br>
<br>
</span>How do you propose to store raw thumbnails then? I don't really know how<br>
digikam stores thumbnails for other types, or even if it stores something or<br>
simply generate them online.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Gilles Caulier<br>
><br>
> > On sábado, 7 de enero de 2017 12:33:43 (CET) Remco Viëtor wrote:<br>
> > > On samedi 7 janvier 2017 10:31:27 CET Gilles Caulier wrote:<br>
> > > > I follow this thread, and that i can said is : RAW workflow is<br>
> > > > terrific<br>
> > > > and<br>
> > > > very complex. I spare few years to undstand all main subtilities to<br>
> > > > implement a first suitbale support of RAW files in digiKam.<br>
> > > ><br>
> > > > Read the contextual responses below for the next...<br>
> > > ><br>
> > > > 2017-01-07 10:15 GMT+01:00 Remco Viëtor <<a href="mailto:remco.vietor@wanadoo.fr">remco.vietor@wanadoo.fr</a>>:<br>
> > > > > On samedi 7 janvier 2017 03:42:35 CET Juan Jose Casafranca wrote:<br>
> > > > > > I know that darktable writes not only tags, rating etc, but also<br>
> ><br>
> > the<br>
> ><br>
> > > > > > process history.<br>
> > > > > ><br>
> > > > > > That's why I want digikan to call darktable when it founds a raw<br>
> ><br>
> > file.<br>
> ><br>
> > > > > > (...)<br>
> > > > ><br>
> > > > > Wouldn't it be easier to get an option in Darktable to write a<br>
> ><br>
> > thumbnail<br>
> ><br>
> > > > > file<br>
> > > > > to disk when leaving darkroom mode or changing file there? And then<br>
> ><br>
> > add<br>
> ><br>
> > > > > a<br>
> > > > > link<br>
> > > > > to that thumbnail in the XMP file. Basically, you add an API for<br>
> > > > > external<br>
> > > > > programs to provide a thumbnail image (and afaik, KDE has a<br>
> ><br>
> > standardised<br>
> ><br>
> > > > > way<br>
> > > > > to store thumbnails in a directory).<br>
> > > ><br>
> > > > This API is limited even if it's standardized by Open Desktop. digiKam<br>
> > > > drop<br>
> > > > this support since a while for multiple technical reasons, as using<br>
> > > > Wavelets compression to reduce space instead PNG, using a dedicted<br>
> > > > database<br>
> > > > to handle disconnected removable media, be able to store thumb in a<br>
> ><br>
> > remote<br>
> ><br>
> > > > database, support more than 256x256 thumbnails size, etc...<br>
> > > ><br>
> > > > So no KDE API here. In all case, we want to reduce to the max KDE<br>
> > > > dependencies for the future to be porta le everywhere and reduce<br>
> > > > complexity.<br>
> > > ><br>
> > > > Note : KDE thumbnials use KIO : we drop this support since 5.0, which<br>
> ><br>
> > DO<br>
> ><br>
> > > > NOT WORK outside Linux, and cannot be bundled in AppImage. No KIO in<br>
> > > > digiKam for the future...<br>
> > ><br>
> > > OK, so that is not a viable option. But a clear way for external<br>
> ><br>
> > programs to<br>
> ><br>
> > > get information (like thumbnails) back to Digikam would be helpful, and<br>
> ><br>
> > the<br>
> ><br>
> > > sidecar could be a channel for that.<br>
> > ><br>
> > > > > And Darktable already generates preview<br>
> > > > > images/thumbnails (top left in the darkroom window, and of course in<br>
> > > > > lighttable mode). Better to reuse those if at all possible.<br>
> > > ><br>
> > > > Where are stored this preview image ? In a dedicated place... This<br>
> ><br>
> > will be<br>
> ><br>
> > > > another puzzle to interface digiKam with that...<br>
> > ><br>
> > > Ideally, Digikam shouldn't have to worry about if and where those<br>
> ><br>
> > thumbnails<br>
> ><br>
> > > are stored internally by Darktable. But the code to *generate* those<br>
> > > thumbnails is in place already, what's missing is a way to *export*<br>
> > > those<br>
> > > thumbnails for use with external programs (i.e. Digikam).<br>
> > ><br>
> > > > > It's clear that Digikam's editor will not be able to generate a<br>
> > > > > thumbnail<br>
> > > > > from<br>
> > > > > the original RAW<br>
> > > ><br>
> > > > Wrong. digiKam use libraw and extract JPEG preview from RAW file to<br>
> > > > generate thumbnails...<br>
> > > ><br>
> > > > > and a Darktable XMP. But starting Darktable for each and<br>
> > > > > (...)<br>
> > ><br>
> > > Sorry, you cut my phrase at the wrong point...<br>
> > > What I wanted to say is that Digikam cannot repeat the processing<br>
> ><br>
> > Darktable<br>
> ><br>
> > > does, i.e. cannot generate a thumbnail by combining the information from<br>
> ><br>
> > the<br>
> ><br>
> > > RAW file and the XMP file (of course Digikam can generate a thumbnail<br>
> ><br>
> > from<br>
> ><br>
> > > the RAW file only, it's doing just that all the time...)<br>
> > ><br>
> > > > A possible solution is to use IPTC field stored in XMP. There is a<br>
> > > > IPTC<br>
> > > > preview tag to host JPEG preview. It's limited to 256Kb of data which<br>
> ><br>
> > is<br>
> ><br>
> > > > enough to do the job. Problem : Old IPTC support is, in XMP i don't<br>
> ><br>
> > know,<br>
> ><br>
> > > > especially to host binary data in XML.<br>
> > > ><br>
> > > > Other problem is to explode the sidecar XMP file size. This is why we<br>
> ><br>
> > use<br>
> ><br>
> > > > a<br>
> > > > dedicted database....<br>
> > > ><br>
> > > > > Another problem with that would be all the other RAW processors out<br>
> > > > > there.<br>
> > > > > Why<br>
> > > > > would Digikam treat Darktable in a special way and ignore all the<br>
> > > > > others?<br>
> > > ><br>
> > > > Remember that we use already a RAW processor : libraw. there are<br>
> ><br>
> > plenty of<br>
> ><br>
> > > > new feature in this processor not yet used in digiKam. The best way is<br>
> ><br>
> > to<br>
> ><br>
> > > > implment new RAW feature in digiKam, at least to import RAW data in<br>
> > > > editor.<br>
> > ><br>
> > > Possible, but not relevant to this subject (IMO): there are many reasons<br>
> ><br>
> > why<br>
> ><br>
> > > someone would use Digikam for DAM, and another program for RAW<br>
> ><br>
> > development.<br>
> ><br>
> > > The point here is to get a *representation* of the image, as produced by<br>
> > > that other program, in the Digikam thumbnails view.<br>
> > ><br>
> > > So, basically, what I'd aim for is:<br>
> > > - define a way to get thumbnails from an external source into Digikam;<br>
> > > - get the external programs to provide (access to) those thumbnails in a<br>
> > > well- defined way;<br>
> > > - find a way to make sure Digikam won't import unchanged thumbnails a<br>
> ><br>
> > second<br>
> ><br>
> > > time.<br>
> > ><br>
> > > Remco<br>
<br>
<br>
</div></div></blockquote></div><br></div>