Digikam raw files and darktable

[Gilles Caulier]

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/c3bb6b7a/attachment.html>