<div dir="ltr">And this will duplicate data and slowdown the thumbnails processing. Definitively, it's wrong.<div><br></div><div>Gilles Caulier</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-07 12:55 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">Even more, if digikam stores thumbnails in a folder and just link the database<br>
entry to the thumbnail path, then is pretty straightforward for the raw<br>
processor to send the thumbnail back, just export the processed image to the<br>
desire path and the desired size.<br>
<div class="HOEnZb"><div class="h5"><br>
On sábado, 7 de enero de 2017 12:51:23 (CET) you wrote:<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 in<br>
> the database, then, the only thing needed is a way to generate the processed<br>
> raw as a thumbnail and a flag which specify if the thumbnail is up to date.<br>
><br>
> This flag es very easy to maintain. When loading the database, the<br>
> thumbnails are not up to date. So darktable (or any other raw processor)<br>
> will be called to generate the thumbnails. When a raw file is opened for<br>
> edition through the digikam interface, then also mark the thumbnail is not<br>
> up to date. If the user opens the file for edition from other place<br>
> different from the digikam interface (opening the raw processor directly<br>
> for example), then do anything. I know that thumbnail stored and the<br>
> processed image will not match in this case, this should be documented.<br>
> Enable an option to update manually the thumbnails for raw files.<br>
><br>
> Digikam should have an option to choose which raw processor want the user to<br>
> user. Default one, darktable, raw therapee, whatever. When a user try to<br>
> edits 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 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 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>
> User opens a raw file in digikam -> darktable is opened<br>
> User edits in darktable and close it -> thumbnail is marked as not up to<br>
> date Thumbnail is updated calling darktable which returns an image (maybe<br>
> with a LUA script?)<br>
> The thumbnail is stored in digikam the same way other jpeg or current raw<br>
> thumbnails are stored<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 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 the<br>
> > > > > process history.<br>
> > > > ><br>
> > > > > That's why I want digikan to call darktable when it founds a raw<br>
> > > > > file.<br>
> > > > > (...)<br>
> > > ><br>
> > > > Wouldn't it be easier to get an option in Darktable to write a<br>
> > > > thumbnail<br>
> > > > file<br>
> > > > to disk when leaving darkroom mode or changing file there? And then<br>
> > > > add<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>
> > > > standardised<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>
> > > remote<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 DO<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 programs<br>
> > to get information (like thumbnails) back to Digikam would be helpful,<br>
> > and the 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 will<br>
> > > be<br>
> > > another puzzle to interface digiKam with that...<br>
> ><br>
> > Ideally, Digikam shouldn't have to worry about if and where those<br>
> > thumbnails are stored internally by Darktable. But the code to *generate*<br>
> > those thumbnails is in place already, what's missing is a way to *export*<br>
> > those 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>
> > Darktable<br>
> > does, i.e. cannot generate a thumbnail by combining the information from<br>
> > the RAW file and the XMP file (of course Digikam can generate a thumbnail<br>
> > from 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 IPTC<br>
> > > preview tag to host JPEG preview. It's limited to 256Kb of data which is<br>
> > > enough to do the job. Problem : Old IPTC support is, in XMP i don't<br>
> > > know,<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>
> > > use<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 plenty<br>
> > > of<br>
> > > new feature in this processor not yet used in digiKam. The best way is<br>
> > > to<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>
> > why someone would use Digikam for DAM, and another program for RAW<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>
> > second time.<br>
> ><br>
> > Remco<br>
<br>
<br>
</div></div></blockquote></div><br></div>