Digikam raw files and darktable

Sat Jan 7 16:30:53 GMT 2017

Yes, I don't want digikam developers to do this. I understand that they
have their own roadmap. Opensource strength is the possibility for any user
to propose changes and implement them if they know how to do it :-)

I'm already coding a kind of very stupid version of what I want, just to
play around with it and see how things can be done. But I must say that it
looks pretty simple. This first toy code is just calling darktable-cli,
saving an image to disk and loading it as a thubnail. Its just to see how
things could be done afterwards :-)

I also think the DBus option is the best one, although it's only Linux
available so I will have a look at it

2017-01-07 17:25 GMT+01:00 Andrey Goreev <aegoreev at gmail.com>:

> We definitely don't want digikam developers to do any extra work for that.
> They have their roadmap and want to stay on it. What we want from them is
> to tell us how could importing thumbnails from darktable to digikam be done
> with absolute minimal changes in the digikam code. Am I correct ?
>
> Also, if the Linux only solution (DBus) is the simplest solution I think
> we should stick to it. I am actually a windows user and there is no
> darktable version for Windows so I created a designated virtual machine
> (ubuntu studio) and do all DAM and photo / video processing there. The
> pictures folder can be accessed from both Windows and Linux so there is
> nothing that needs to be done twice. Any changes can be seen in any OS.
>
>
> Sent from my Samsung Galaxy smartphone.
>
> -------- Original message --------
> From: Juan Jose Casafranca <jjcasmar at gmail.com>
> Date: 2017-01-07 8:59 AM (GMT-07:00)
> To: digiKam - Home Manage your photographs as a professional with the
> power of open source <digikam-users at kde.org>
> Subject: Re: Digikam raw files and darktable
>
>
>
> 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...
>>
>
> I'm not asking to change the raw processor. Just asking to allow the user
> which raw processor wants to use. If the user selects to use DT, simply
> make him enter the DT executable which will be called when the raw file
> must be processed. No dependency needed.
>
>
>>
>>> 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/a789c533/attachment.html>