<div dir="ltr">I follow this thread, and that i can said is : RAW workflow is terrific and very complex. I spare few years to undstand all main subtilities to implement a first suitbale support of RAW files in digiKam.<div><br></div><div>Read the contextual responses below for the next...<br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-07 10:15 GMT+01:00 Remco Viëtor <span dir="ltr"><<a href="mailto:remco.vietor@wanadoo.fr" target="_blank">remco.vietor@wanadoo.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>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. To<br>
> generate the processed image.<br>
><br>
> Do you have any idea about digikam code? I see that people is interested in<br>
> this feature, so tomorrow I will try to define the tasks for the project<br>
> and I will share them in the bug I have create for this.<br>
<br>
</span>Wouldn't it be easier to get an option in Darktable to write a thumbnail file<br>
to disk when leaving darkroom mode or changing file there? And then add a link<br>
to that thumbnail in the XMP file. Basically, you add an API for external<br>
programs to provide a thumbnail image (and afaik, KDE has a standardised way<br>
to store thumbnails in a directory).</blockquote><div><br></div><div>This API is limited even if it's standardized by Open Desktop. digiKam drop this support since a while for multiple technical reasons, as using Wavelets compression to reduce space instead PNG, using a dedicted database to handle disconnected removable media, be able to store thumb in a remote database, support more than 256x256 thumbnails size, etc...</div><div><br></div><div>So no KDE API here. In all case, we want to reduce to the max KDE dependencies for the future to be porta le everywhere and reduce complexity.</div><div><br></div><div>Note : KDE thumbnials use KIO : we drop this support since 5.0, which DO NOT WORK outside Linux, and cannot be bundled in AppImage. No KIO in digiKam for the future...</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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></blockquote><div><br></div><div>Where are stored this preview image ? In a dedicated place... This will be another puzzle to interface digiKam with that... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It's clear that Digikam's editor will not be able to generate a thumbnail from<br>
the original RAW</blockquote><div><br></div><div>Wrong. digiKam use libraw and extract JPEG preview from RAW file to generate thumbnails...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and a Darktable XMP. But starting Darktable for each and<br>
every RAW file that has a Darktable XMP is going to be slow (even if you can<br>
reliably detect whether an image has been changed). So at the very least,<br>
starting Darktable to generate thumbnails would have to be optional or a batch<br>
process.<br></blockquote><div><br></div><div>A possible solution is to use IPTC field stored in XMP. There is a IPTC preview tag to host JPEG preview. It's limited to 256Kb of data which is enough to do the job. Problem : Old IPTC support is, in XMP i don't know, especially to host binary data in XML.</div><div><br></div><div>Other problem is to explode the sidecar XMP file size. This is why we use a dedicted database....</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another problem with that would be all the other RAW processors out there. Why<br>
would Digikam treat Darktable in a special way and ignore all the others?<br>
<br></blockquote><div><br></div><div>Remember that we use already a RAW processor : libraw. there are plenty of new feature in this processor not yet used in digiKam. The best way is to implment new RAW feature in digiKam, at least to import RAW data in editor.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For the record, I use Darktable as primary editor, and getting the processed<br>
images visible in Digikam would be nice. I'm not sure this should be addressed<br>
(only) from the Digikam side, though.<br>
</blockquote></div><br></div></div><div class="gmail_extra">exactly...</div><div class="gmail_extra"><br></div><div class="gmail_extra">Gilles Caulier</div></div>