Digikam raw files and darktable

[Boudewijn]

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. 



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/20170114/9c7163c7/attachment.html>