RAW workflow on Linux?

One of my resolutions for 2015 is to try harder at this "RAW" thing.  So far I've been shooting (film digitized to) JPEG most of the time.  Primarily for lack of (time to test) good workflow solutions under Linux.

For JPEG, I've been quite happy with Shotwell for my general DAM workflow and some basic global edits (crop, rotate, saturation, contrast, exposure) and other editors (GIMP) as needed for dust removal or stronger retouching requirements.  I'm overwriting the original JPEG for scanned film (I could still re-scan it to get back to a pristine scan if I wanted to) or I can choose to create a new version and Shotwell can manage it as a derivative of the original without too many difficulties.  So I use Shotwell to catalog, title, describe, tag, rate (stars), organize (events) and publish/export.  Import is slow and unreliable to I switched the task of emptying my cards back to gThumb (nicely done) and it writes directly into my photo directories (by year/month/day) where Shotwell will safely auto-import them.  Strangely enough Shotwell doesn't crash on auto-import, only on copy/import.  Go figure... Also export used to work fine (but never was able to transfer the descriptions to Flickr, only the title appeared in both title and description) but as of Shotwell 20.2 there was a bug (on Ubuntu) when publishing.  So I switched back for a while to manual export/upload (using Flickr web interface) then to export/mail upload (using a homebrewed script to set tags, titles and descriptions as they should be set).  So far so good for JPEG only work...

For RAW, in 2014 I've done several attempts at using Shotwell to do the same.  However, I quickly found out that Shotwell works fine with RAW+JPEG and even RAW only (I used developer=camera) but that doesn't give me any advantage over shooting JPEG since I end up with the same JPEG image as provided by the processor in the camera, plus a bloated and so far useless RAW file on my disk.  If I really want to develop the RAW file I could use developer=shotwell (but then I don't get any manual control over the conversion process AFAIK) or create my own JPEG by opening each RAW (from within Shotwell or not) and maybe storing the result in the Shotwell-managed folders.  This will quickly make it pretty hard to manage (each keeper will appear at least twice in Shotwell and 3 files will be kept: RAW, Shotwell-JPEG, my JPEGs)...  Not so much a problem for disk space (cheap enough by now) but more a problem when it comes to managing the whole thing (what do I still need to process/rate/tag/tweak/publish?).  Another issue is that Shotwell (or its libraries) refuse to write any metadata back to the JPEG file as soon as a RAW or RAW+JPEG pair is part of the equation.  I can understand that some people don't want any software to ever touch the original RAW but I can't understand why this would also apply to the JPEG (especially when the format does provide support for metadata updates-e.g. DNG...).  That raises the issue about potential lock-in, or data loss in case of database corruption, or lack of interoperability with other software.

So I've decided that the current shotwell feature set is not satisfactory for RAW processing, at least as a standalone solution.  I might still make another attempt at using a RAW developer from within Shotwell and see if somehow I can overwrite the Shotwell-generated JPEG so as to keep the pairing between the RAW and derived JPEG.  Maybe that could help especially if the RAW developer can write metadata in such a way that Shotwell could read them and update its database accordingly.  That way I would not need the RAW software to also do my DAM, I could still continue to use Shotwell for this, and would not even need to develop the RAW as long as the automatically produced JPEG was good enough for my purposes.  Well I would still need something to write metadata to that JPEG then I guess...

So I made a number of tests with other software packages, that will be a subject for the next posts.