Digikam raw files and darktable

[Juan Jose Casafranca]

I have a 5 idea, just tell what you think about it.

When digikam founds a raw file, call the raw processor to process the raw
file using the xmp file.
Get the returned image and store it in the database the same way other
thumbnails are stored.

Darktable writes its history in an xmp file, so the only thing needed is
both software dont override the info written by the other software.

So when digikam needs the processed image, simply calls DT and gives the
current xmp file. If its the first time darktable sees that image, then it
would write the default history and return the image. If the xmp file
already has a DT history, it would return the image that result from that
iamge. If the user want to manipulate the image, simply open DT from
digikam interface and when it's closed, recover the image (the xmp file
will have the DT history).

I think its a pretty easy way to do it. Do you think there is any issue
with this idea?

2017-01-07 16:22 GMT+01:00 Gilles Caulier <caulier.gilles at gmail.com>:

>
>
> 2017-01-07 15:41 GMT+01:00 Juan Jose Casafranca <jjcasmar at gmail.com>:
>
>> On sábado, 7 de enero de 2017 15:25:43 (CET) Gilles Caulier wrote:
>> > 2017-01-07 15:22 GMT+01:00 Juan Jose Casafranca <jjcasmar at gmail.com>:
>> > > On sábado, 7 de enero de 2017 15:14:09 (CET) Gilles Caulier wrote:
>> > > > 2017-01-07 15:08 GMT+01:00 Juan Jose Casafranca <jjcasmar at gmail.com
>> >:
>> > > > > On sábado, 7 de enero de 2017 15:03:38 (CET) Gilles Caulier wrote:
>> > > > > > As i explain before, ALL thumbnails generated by digiKam are
>> stored
>> > >
>> > > in a
>> > >
>> > > > > > dedicated database (sqlite or Mysql).
>> > > > > >
>> > > > > > The thumbnails are stored using wavelets compression format PGF
>> to
>> > > > >
>> > > > > optimize
>> > > > >
>> > > > > > space. In older DK version (3 for ex), we use FreeDesktop way
>> with
>> > >
>> > > PNG
>> > >
>> > > > > > which explode storage for huge collection and take a while to
>> store
>> > > > > > thumbnails files. Also FreeDesktop recommendations is only
>> limited
>> > > > > > to
>> > > > > > 256x256, which is not enough for Hdpi screen (digiKam can store
>> > >
>> > > 512x512
>> > >
>> > > > > and
>> > > > >
>> > > > > > perhaps more in the future with 8K screen).
>> > > > >
>> > > > > Okay. But there is no need to change anything in DK for storing
>> > > > > thumbnails.
>> > > > > The only thing needed is to change the way thumbnails are
>> generated
>> > > > > and
>> > > > > updated for raw files.
>> > > > >
>> > > > > Simply, when DK finds a new raw file, instead of loading the
>> embedded
>> > >
>> > > jpg
>> > >
>> > > > > file,
>> > > > > simply call the raw processor and generate the new file. And when
>> the
>> > > > > thumbnail
>> > > > > is dirty (as I explained before), regenerate the thumbnail.
>> > > >
>> > > > But this is already the case. We use already a raw decoder named
>> libraw
>> > >
>> > > to
>> > >
>> > > > process RAW thumbnails. We will not using another one... Stop to
>> puzzle
>> > >
>> > > the
>> > >
>> > > > code
>> > > >
>> > > > Gilles Caulier
>> > >
>> > > So you are telling me that if we want to process a raw file and
>> manage a
>> > > library with DK, we have to stay with the simply DK raw processor
>> instead
>> > > of
>> > > using a much more powerful one like darktable? Do you really think
>> that
>> > > people
>> > > out there use the DK raw processor to process their images?
>> >
>> > But digiKam is not DarkTable.  The way to mix both cannot be done. This
>> is
>> > 2 different applications, one written in Qt other one in GTK...
>> >
>> > The goal currently in DK is to stabilize the code, reduce dependencies,
>> > improve port to non Linux. We have plenty of jobs to do, DarkTable is
>> not a
>> > priority for the moment.
>> >
>> > Gilles Caulier
>>
>> I know that they are two different apps. I dont understand why GTK and Qt
>> is
>> even a question here. I'm not saying to add DT as a depency for DK, just
>> let
>> the user decide which raw processor uses.
>>
>
> But Raw processor from DT is not the same than DK as i know. Changing Raw
> processor in digiKam by DT one is as to add DT dependencies to DK.  No way
> here...
>
>>
>> As I said, I can try to develop this by myself, I'm not asking any
>> dedicated
>> DK developer to do it... What I only need is a little guideline on how the
>> thumbnails are generated, how they are stored in the database and some
>> other
>> stuff for letting the user choose which processor wants to choose.
>>
>
> 2 possibilities :
>
> 1/ use DBus to ping digiKam core about thumbnails changed externally. Only
> Linux solution.
>
> 2/ use XMP sidecar to store a local path to new thumbnails processed into
> DT XMP namespace. I don't like this too much by at least it store the
> minimum to XMP.
>
> 3/ store wavelets compressed preview in XMP sidecar to
> Iptc.Application2.Preview
>
> 4/ use a thumbnail sidecar file near RAW file as .thumb. I see this
> solution already used under Windows, but i don't remember which application
> exactly. I know that Canon camera do it also. It's a simple JPEG file with
> metadata This way will duplicata data of course.
>
> Gilles Caulier
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20170107/0a69504d/attachment.html>