Digikam raw files and darktable

[Juan Jose Casafranca]

Is that a darktable only solution? I dont want a darktable only solution
but a global solution, for several raw processors. When I say darktable,
its because its the raw processor I use, not because it deserves a special
treatment.

I still think that a solution  in which dk calls the raw processor to
generate the processed image is the best.

El 14 ene. 2017 22:47, "Boudewijn" <wankelwankel at yahoo.com> escribió:

> Hi Juan,
>
>
>
> Maybe there is one more option. The solution in this case is in darktable
> instead of in digiKam:
>
>
>
> * have DT store an export of the current state of processing as PGF in
> DK's thumbs database, overwriting the current thumbnail for DK
>
> * use an external database for DK, so that it is accessible even when DK
> is not running
>
>
>
> The first hurdles I see are:
>
> * storage options of DT do not include 'save in database' as target storage
>
> * storage options of DT do not include 'PGF' as file format option
>
> * I have never had a look in the thumbs-db, and no idea whether the
> thumbnailname is identical to the file name
>
>
>
> It seems that there are Lua-options to work with PGF, there are
> MySQL-Lua-bindings and DT can use Lua scripts, so it may be a viable path.
>
>
>
> The result would be that DK 'just shows' the thumbnail of latest version
> of the photo, even without knowing it does. Whenever you're sick of seeing
> the thumbnail of the latest version of the photo, you open the photo (via
> any route) in DT, go back to a previous step and save the new thumbnail to
> the database.
>
>
>
> Best regards,
>
>
>
> Boudewijn
>
>
>
> PS, the thumbnail maintenance may be this code (please correct me if
> wrong!), I see insert, replace and update being handled by id, where the
> thumbnails.id = thumbid from filepath.
>
>
> https://cgit.kde.org/digikam.git/tree/libs/database/thumbsdb/thumbsdb.cpp
>
>
>
> QHash<QString, int> ThumbsDb::getFilePathsWithThumbnail()
>
> {
>
> DbEngineSqlQuery query = d->db->prepareQuery(QString::fromLatin1("SELECT
> path, id "
>
> "FROM FilePaths "
>
> " INNER JOIN Thumbnails ON FilePaths.thumbId=Thumbnails.id "
>
> "WHERE type BETWEEN %1 AND %2;")
>
> .arg(DatabaseThumbnail::PGF)
>
> .arg(DatabaseThumbnail::PNG));
>
>
>
> if (!d->db->exec(query))
>
> {
>
> return QHash<QString, int>();
>
> }
>
>
>
> QHash <QString, int> filePaths;
>
>
>
> while (query.next())
>
> {
>
> filePaths[query.value(0).toString()] = query.value(1).toInt();
>
> }
>
>
>
> return filePaths;
>
> }
>
>
>
> BdEngineBackend::QueryState ThumbsDb::replaceThumbnail(const
> ThumbsDbInfo& info)
>
> {
>
> return d->db->execSql(QLatin1String("REPLACE INTO Thumbnails (id, type,
> modificationDate, orientationHint, data) VALUES(?, ?, ?, ?, ?);"),
>
> QList<QVariant>() << info.id << info.type << info.modificationDate <<
> info.orientationHint << info.data);
>
> }
>
>
>
>
>
> On zaterdag 14 januari 2017 01:39:11 CET Juan Jose Casafranca wrote:
>
> > I havent thought it that way since Ive always use nikon cameras, but ypu
>
> > may be right.
>
> >
>
> > Anyway, as I said, lets try to hace a working concept for a global raw
>
> > processor and after that, think about other necessities.
>
> >
>
> > This weekend Ill begin to study DK code to try to find a way of
>
> > implementing this feature.
>
> >
>
> > Thanks for the tips :-)
>
> >
>
> > El 13 ene. 2017 11:57 PM, "cerp" <cerp at eeos.biz> escribió:
>
> >
>
> > Dear Juan,
>
> >
>
> > I am not sure people use always the same editor. People may have more
> than
>
> > one camera using different RAW format, and you tend to use the best RAW
>
> > editor for the specific format. For example, we use a combination of
>
> > editors. Even proprietary software we have used CaptureOne, Lightroom and
>
> > Silkypix, depending on the camera (CaptureOne and Lightroom for the
> Leica,
>
> > Silkypix for the RAF).
>
> >
>
> > This is even more true in the OS environment.
>
> >
>
> >
>
> > Best,
>
> >
>
> > Quoting Juan Jose Casafranca <jjcasmar at gmail.com>:
>
> >
>
> > More or less. I prefer to think that the user has defined a default raw
>
> >
>
> > > processor (normally, users only use one raw processor, dont they?) and
> all
>
> > > the raw files will be decoded using that raw processor in order to
>
> > > generate
>
> > > the thumbnail and preview image. When the user opens that file, it
> will be
>
> > > opened in the default raw processor and after the edition is done,
>
> > > thumbnail will be updated accordingly.
>
> > >
>
> > > Maybe allowing the user to select a specific raw processor for a
> specific
>
> > > raw file can be done, but lets do things one step at a time. The
> original
>
> > > idea is already hard for me, as I've never worked neither with digikam
>
> > > code
>
> > > nor any other raw processor but DT.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20170115/c934a562/attachment.html>