Digikam raw files and darktable

Sun Jan 8 01:20:00 GMT 2017

Just saw this now and have been far far away from DK & DT for a long time,
so sorry if I speak outdated:

I tried to combine both for my workflow before, with limited success. What
I wished for back then was a proper solution in DK for grouping. I wouldn't
mind developing my edits into JPEGs (actually want to, since I may have
multiple edits as someone said earlier). In the past DK didn't group them
well, that's where I had issues. If grouping is working well now I think
the preview topic is not really a serious shortcoming, no?

On Sun, 8 Jan 2017 at 01:27, Juan Jose Casafranca <jjcasmar at gmail.com>
wrote:

> Could you look if there is anyway to ask darktable for an image through
> DBus? The image should be returned without been saved in disk.
> (As a char* for example).
>
> Right now I'm trying to understand how digikam asks for the thumbnails and
> for the preview images so I can ask for them when it's necessary.
>
> 2017-01-07 18:20 GMT+01:00 Andrey Goreev <aegoreev at gmail.com>:
>
> I agree 100%. I am willing to help if needed
>
>
>
> Sent from my Samsung Galaxy smartphone.
>
> -------- Original message --------
> From: Juan Jose Casafranca <jjcasmar at gmail.com>
> Date: 2017-01-07 9:30 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
>
> 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/20170108/1b169244/attachment.html>