Digikam raw files and darktable

[Gilles Caulier]

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. To
> > generate the processed image.
> >
> > Do you have any idea about digikam code? I see that people is interested
> in
> > this feature, so tomorrow I will try to define the tasks for the project
> > and I will share them in the bug I have create for this.
>
> 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...





> 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...

>
> 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
> every RAW file that has a Darktable XMP is going to be slow (even if you
> can
> reliably detect whether an image has been changed). So at the very least,
> starting Darktable to generate thumbnails would have to be optional or a
> batch
> process.
>

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.


> For the record, I use Darktable as primary editor, and getting the
> processed
> images visible in Digikam would be nice. I'm not sure this should be
> addressed
> (only) from the Digikam side, though.
>

exactly...

Gilles Caulier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20170107/4f6177b6/attachment.html>