Digikam raw files and darktable

[Remco Viëtor]

On samedi 7 janvier 2017 10:31:27 CET Gilles Caulier wrote:
> 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.
> 
> Read the contextual responses below for the next...
> 
> 2017-01-07 10:15 GMT+01:00 Remco Viëtor <remco.vietor at wanadoo.fr>:
> > On samedi 7 janvier 2017 03:42:35 CET Juan Jose Casafranca wrote:
> > > I know that darktable writes not only tags, rating etc, but also the
> > > process history.
> > > 
> > > That's why I want digikan to call darktable when it founds a raw file.
> > > (...)
> > 
> > Wouldn't it be easier to get an option in Darktable to write a thumbnail
> > file
> > to disk when leaving darkroom mode or changing file there? And then add a
> > link
> > to that thumbnail in the XMP file. Basically, you add an API for external
> > programs to provide a thumbnail image (and afaik, KDE has a standardised
> > way
> > to store thumbnails in a directory).
> 
> 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...
> 
> 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.
> 
> 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...

OK, so that is not a viable option. But a clear way for external programs to 
get information (like thumbnails) back to Digikam would be helpful, and the 
sidecar could be a channel for that.

> > And Darktable already generates preview
> > images/thumbnails (top left in the darkroom window, and of course in
> > lighttable mode). Better to reuse those if at all possible.
> 
> Where are stored this preview image ? In a dedicated place... This will be
> another puzzle to interface digiKam with that...
> 
Ideally, Digikam shouldn't have to worry about if and where those thumbnails 
are stored internally by Darktable. But the code to *generate* those 
thumbnails is in place already, what's missing is a way to *export* those 
thumbnails for use with external programs (i.e. Digikam).

> > It's clear that Digikam's editor will not be able to generate a thumbnail
> > from
> > the original RAW
> 
> Wrong. digiKam use libraw and extract JPEG preview from RAW file to
> generate thumbnails...
> 
> > and a Darktable XMP. But starting Darktable for each and
> > (...)

Sorry, you cut my phrase at the wrong point...
What I wanted to say is that Digikam cannot repeat the processing Darktable 
does, i.e. cannot generate a thumbnail by combining the information from the 
RAW file and the XMP file (of course Digikam can generate a thumbnail from the 
RAW file only, it's doing just that all the time...)

> 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.
> 
> Other problem is to explode the sidecar XMP file size. This is why we use a
> dedicted database....
> 
> > Another problem with that would be all the other RAW processors out there.
> > Why
> > would Digikam treat Darktable in a special way and ignore all the others?
> 
> 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.

Possible, but not relevant to this subject (IMO): there are many reasons why 
someone would use Digikam for DAM, and another program for RAW development.

The point here is to get a *representation* of the image, as produced by that  
other program, in the Digikam thumbnails view.

So, basically, what I'd aim for is:
- define a way to get thumbnails from an external source into Digikam;
- get the external programs to provide (access to) those thumbnails in a well-
defined way;
- find a way to make sure Digikam won't import unchanged thumbnails a second 
time.

Remco