<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-07 12:51 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">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 thumbnails<br>
are not up to date. So darktable (or any other raw processor) will be called<br>
to generate the thumbnails. When a raw file is opened for edition through the<br>
digikam interface, then also mark the thumbnail is not up to date. If the 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 anything.<br>
I know that thumbnail stored and the processed image will not match in 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 to<br>
user. Default one, darktable, raw therapee, whatever. When a user try to 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 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></blockquote><div><br></div><div>Already possible in Linux desktop, through OpenWith context menu.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
User opens a raw file in digikam -> darktable is opened<br></blockquote><div><br></div><div>Already possible in Linux Desktop, with default application set in desktop, that can be handle through a keyboard shortcut. I introduced myself in 5.0.0. Perhaps this need to be improved, but a good desktop settings in a best start.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
User edits in darktable and close it -> thumbnail is marked as not up to date<br>
Thumbnail is updated calling darktable which returns an image (maybe with a<br>
LUA script?)<br></blockquote><div><br></div><div>DBUS can be used here. It's easy, but... This will only work under Linux. Forget MacOS and Windows, DBUS is a waste of time.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The thumbnail is stored in digikam the same way other jpeg or current raw<br>
thumbnails are stored<br></blockquote><div><br></div><div>On this point, i'm not agree. It"s a regression and an user wish fixed few year ago...</div><div><br></div><div>Gilles Caulier</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><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 file.<br>
> > > > (...)<br>
> > ><br>
> > > Wouldn't it be easier to get an option in Darktable to write a thumbnail<br>
> > > file<br>
> > > to disk when leaving darkroom mode or changing file there? And then 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 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 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 to<br>
> get information (like thumbnails) back to Digikam would be helpful, and the<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 will be<br>
> > another puzzle to interface digiKam with that...<br>
><br>
> Ideally, Digikam shouldn't have to worry about if and where those thumbnails<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* 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 Darktable<br>
> does, i.e. cannot generate a thumbnail by combining the information from the<br>
> RAW file and the XMP file (of course Digikam can generate a thumbnail from<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 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 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 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 of<br>
> > new feature in this processor not yet used in digiKam. The best way is 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 why<br>
> someone would use Digikam for DAM, and another program for RAW 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 second<br>
> time.<br>
><br>
> Remco<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>