On 06/29/2013 09:28 PM, Michael Below wrote:
Hi!
> I am new to darktable. Great program, but there's one point I didn't
> find in the FAQ:
>
> As I understand, darktable doesn't want to be a full image management
> solution, the sorting/tagging etc. is intentionally basic.
Ah? So this seems to have changed then. And it would be quite
unfortunate, and in a way not really logical at all, given the effort
built into setting up a database and stuff. Besides it calls itself
"photography workflow application" and "raw developer". First part
definitely considers db handling, at least in my book.
My feeling is more that "metadata" are not considered as cool as new
processing modules (could even understand this to a certain point), so
there is a lack of developers devoted to it. Know this too well from my
daytime job, usually I'll have to do the metadata stuff myself and other
prefer to do fancy and fancy looking things. ("Unfortunately", the
latter most of the time requires good parts of the former.) Definitely,
metadata is one (if not the) main weakness of DT at the moment, though
my feeling is that if there would be someone with the skills
(unfortunately, DTs backend is beyond my capablities) one could get it
right without too much effort.
> What is the recommended software for image management to use with
> darktable? I have seen digikam recommended, but it doesn't handle the
> darktable sidecar files as it should, IMHO:
AFAIK if DT is not handling the sorting/tagging (generally metadata)
properly, you'll be completely out of luck on the RAW side, and you'd
have to resort to "developed" images. AFAIK no other tool can do DTs own
development itself, it would have to resort to DTs modules for that.
Similarly you can't import RawTherapees sidecar files to DT (even if you
could you'd most likely not get the same results. Maybe similar ones at
best.)
So: if you want to live on RAW only and entirely, then DT has to do the
image database stuff properly.
> I would like to see a preview of my darktable developed RAW in the image
> management software, not a preview of the initial RAW without my
> processing. E.g. if I select a portrait from a larger scene and develop
> for that, afterwards usually I want to find that cropped portrait, not
> the scene. The darktable lighttable does it right, digikam does it
> differently.
Sure. How should Digikam know proprietary settings of DT?
Though the sidecar as such is a normalized XML all parameters for the
modules are still proprietary stuff, even the module as such is
proprietary to DT. Surely, e.g. DT's shadow & highlights is different
from Dikikams or LightRooms modules for this (if they have an equivalent
at all).
From an archival point of view this has the logical consequence, that
besides the RAW and the sidecars, one also needs to archive the given
version of the RAW developer, in this case DT to be able to reproduce a
result. (BTW: it would be nice if the sidecar would contain the git
commit of DT used for processing, just for this reason.) Given this, it
is in a way questionable whether one should really rely on archiving the
RAW and the XMP only. At least if one wants to keep the final result of
ones work. (I think the latter is the usual idea, right? So it's not
only about bitstream preservation here alone.)
> Any thoughts on this?
Well, what I do at the moment is to use DT for development only. I don't
even use the tagging. Recently tried that again for one project, but it
is just not efficient if one wants to add larger amounts of metadata to
even a smaller collection of say ~200 images. So, after development I
export images to JPG. This condenses all my work done in the raw
processing to a final image, which is what you'd like to have in the end
as well, though I understood that you'd like to avoid the additional
file. One could (should?) go for TIFF here (would be better from a long
term preservation perspective and even for later editing in external
tools), but the tool I use relies on JPG.
For metadata, archiving, searching I use then a software that handles
the JPG nicely and just treats the RAW as well as the XMP like sidecar
files to those JPGs. So basically the image archive is built around the
JPG not the raw+xmp. The tool I use for this is mapivi (probably tcl/tk
doesn't look cool, but I found mapivi the most efficient tool available,
and I can easily write a plugin in perl if needs be). There I do all
keywording and other metadata (like IPTC location settings and so on)
and I use this other app as main image database. If I want to work on a
RAW again I just copy it back to "darkroom/" and run DT against this
dir, export to JPG again apply my old metadata to the new product and
ingest the new edition. Most of this is done by a few lines of perl for
file copy to and fro and the exiftool-lib/shell tools.
Though working, this is definitely not perfect and I admit that I'd
appreciate better metadata handling in dt very much to use it as an
image database as well. I could even adopt to some of the more special
concepts of dt easily, I even like some of them.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Darktable-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/darktable-users
