Digikam raw files and darktable

[Juan Jose Casafranca]

Thats a way of doing things. I usually do different editions and I dont
export any of them at least I need to send them somewhere. Thats why I need
to see the different views for the different xmps :-)

El 8 ene. 2017 2:35, "HaJo Schatz" <hajo at hajo.net> escribió:

> I usually do a "base development" of each RAW. then export this. Then I
> have some pre-set styles I might apply, e.g. a specific B/W style. That
> goes on top of my base development. I'd like to have JPEGs exported at both
> steps and grouped properly, then my world would be fine :)
>
> On Sun, 8 Jan 2017 at 09:30, Juan Jose Casafranca <jjcasmar at gmail.com>
> wrote:
>
>> I don't know about grouping. Each time I have tried to use DK as my
>> management software I quit because I can't update the thumbnails...
>>
>> If you develop your edits as JPEG because you have several of them, how
>> do you later continue developing one of them because you want to do
>> something else from that point? If you modify the history to do a
>> completely different edit, you lose the other. If you duplicate in DT your
>> image, you cant see both files in DK. If you duplicate the whole raw file
>> so you can see it in DK, you don't know which one is each because
>> thumbnails are outdated and don't represent what the editor has done with
>> the raw file.
>>
>> That's why I want a way to update thumbnails and previews with the
>> current editing history...
>>
>> 2017-01-08 2:20 GMT+01:00 HaJo Schatz <hajo at hajo.net>:
>>
>> 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/a90c3675/attachment.html>