I use Rapid Photo Downloader to load my photos to my computer. I use keyword-rich directory names to make it easy to find photos by date, camera used, and subject matter.
I use Geeqie to cull the garbage and quickly decide what I want to edit.
On Linux, I launch darktable from Geeqie. I’m not near that machine right now to get the command string, but it includes --library :memory:
On Windows, I altered the command for the darktable icon to "C:\Program Files\darktable\bin\darktable.exe" --library :memory:
This may not stand up for someone that takes tens of thousands of photos a year and is heavily into tagging, but it makes my life simple.
I am not really sure what DAM is, but guessing it’s digital access management. Not having looked at the other softwares, my experience if limited to darktable. But I do have software engineering background and perhaps that influences my choices.
Couple of years back I thought darktable was not good enough for my needs when it comes to searching for tags or in general. I even created a prototype of what I had in mind and presented it on developers list. They were very polite and nice and pointed me that most of the functionality that I was trying to build exists and pointed me in the right direction. Of course, I never expected my solution in it’s form to be available especially since I was reading the database that only darktable should be reading/managing.
From my needs perspective, only major thing I miss is a tag cloud - not sure if it’s part of DAM, but more like how I view data. I do understand I am a bumbling hobbyist at best when it comes to photography and not a professional whose needs are completely different.
If you don’t integrate DAM and photo editor like in darktable, you would make it more difficult to work only with raws. So, for me the integration is inevitable, otherwise I couldn’t see in the DAM what I did with the raw files. I only export developed raws to jpeg temporarily for internet and delete the jpeg after uploading, so I only keep raws and xmp. That’s why the integration is necessary.
That’s just a technical problem; the raw editor could make it available to the DAM program in various ways (eg embed a decent preview jpeg in the xmp). Currently this does not happen.
Everyone would be better off if the DAM and the raw editor were separate. Darktable devs would not have to maintain something which is essentially orthogonal to the core functionality of DT, while people could pick whatever they prefer from a range of DAM solutions (from “I just put files in directories” to “I maintain an extensive and sophisticated tag cloud collated with geolocation data”).
When I first tried darktable I tagged everything because it was available and it somehow scratched some kind of OCD itch I had (I guess). But it didn’t take long until – for me – it was more effort to tag than the benefits it provided. That’s nothing against darktable, just a reflection of my workflow.
I don’t shoot huge numbers of images, I don’t shoot events / people, family or otherwise (although I’ve been occasionally tempted, if you know what I mean! ), I store everything in dated descriptive folders and after processing (and after backups run) I delete all images that weren’t “keepers”, keeping only raws, sidecars, TIFFs, edited copies (GIMP, whatever) and since they’re small, exported JPGs. Sometimes I’ll go back and delete TIFFs as well later on to save space.
So my workflow is simple:
Copy raws from card to filesystem
View / cull with XnView
Process in raw editor
Finalize in bitmap editor and export
After backups, delete everything I didn’t touch
But I purposely don’t keep extra shots, so I don’t need to search for anything.
I have no system at all. I copy and import, delete brutally, edit and done. Typically export jpegs to iCloud/Photos so they’re in rough date order there as kind of catalogue and place to post to social media or message to friends and rellies. Worry a bit how most people seem to have some complex filing system going on. But then I’ve got 21,000 unread emails in my Mail app.
I suspect if (rhetorically) there are 21K unread emails you probably won’t read them.
One of my managers before I retired (not my current life-long domestic manager!) had over 254,000 job-related messages in her Inbox. Then again, Outlook / Exchange was used as a permanent filing system because we corporately never bothered to pursue anything more appropriate for that type of data. She had been burned by a buggy Outlook rule, so she decided to use no rules at all. Auto-sorting rules (combined with brutal delete practices) was the only method that allowed me to keep a mostly empty Inbox with no unread messages anywhere at all. I had several thousand in total, but I kept on top of it (albeit with effort).
DAM wise LR is brilliant but I’m not bothered about a raw editor being a good DAM, I just want it to be good at editing photos. I use Digikam which is as good as LR for everything that I need. That way I can have all my photos and other things together, I can use different editors and I can use the dev versions without any worry. To be brutally honest I don’t like DT as a DAM but even if it did everything that LR did but even better I still wouldn’t use it as my main DAM because these things being separate suit me.
I do use some of DT’s DAM features so it’s handy editors having them but they should be basic IMO. So DT doesn’t any missing DAM features because it’s a raw editor, would be my response to the people complaining. I just don’t give a DAM.
I think this is an overstatement. It sounds like many in this thread are content with a workflow where photos are grouped together in a folder and edited individually. However having the integrated DAM also makes it easier to perform batch edits across groups of photos.
I think this debate mostly boils down to a question of folders versus tags. For decades we’ve had folder-centric interfaces because some designer made the decision that replicating a digital analog of the physical office desktop of the 1980s would be familiar and therefore easier for people to adopt.
Decades later, we’re still struggling to break free of the artificial limitations imposed by maintaining analogs of the physical world in the digital one.
I prefer the tag-centric approach used by DT. I do have some complaints about the technical implementation of DTs catalog, but I don’t think the solution is to delete the DAM from DT and use a different, more folder-centric tool.
If you don’t like DTs DAM you don’t have to use it, its existence doesn’t cripple it as an editor in any way. In that sense, DT already supports the variety of workflows that have been suggested.
I think the more interesting argument for splitting it out, which I rarely hear, would be if you LIKE DTs DAM but wanted to use it with a different editor instead of DT.
DT’s DAM is one of the reasons I have stuck with DT and not spent a lot of effort testing RT.
Possibly. But since tags have a fairly standardized way of appearing in metadata (xmp), it is precisely the feature that could be implemented in digital asset manager software.
Darktable devs have a lot on their plates, and understandably the focus is on raw processing, since this is where Darktable stands out. Contributing code to the raw processor pipeline usually requires a deep understanding of color science and/or math.
In comparison, contributing to a digital asset manager requires a very different skillset, something that a lot more people have. If the latter was factored out from Darktable, its development could go faster and users of all raw processors could share the benefits.
Previewing edited raw files is a valid concern and is an open technical question. As a stopgap, the Thumbnail Managing Standard allows large (1024px) thumbnails, so raw editor applications are free to save a large preview for culling. Then later on raw editors could agree on a simple api to deliver larger previews from a cache, or generate them on demand.
As a software developer myself, who has made a small contribution to Darktable, I’m unpersuaded by this argument.
If a developer sees an opportunity for improvement to the DAM, they can make that change without touching the pixel pipeline, or having any impact on the ongoing work of the pipeline devs.
Also, the devs working on the pipeline are also users for the DAM. As they are experienced developers who track their code in Git, they are already accustomed to thinking about data management in terms of tags and graphs, not just folders and trees. I think most of them would agree with me that tags are a better model than folders for managing collections of photos.
AP didn’t rage quit because interface development was impeding his pipeline work. He quit over an ideological disagreement with how the project was being lead and managed that he felt was resulting in poor design choices being made and poor quality code getting merged. It just so happened that an interface change was the latest glaring example that he could point to. (That was his perspective, and that perspective is contested. I’m not trying to debate the merits of his arguments, just pointing out that his work was not directly impeded by ongoing development of the DAM interface.)
But that situation itself demonstrates that work on the DAM and it’s interface is ongoing, orthogonally to development of the pipeline.
Conversely, it would be a substantial undertaking at this point to factor out the DAM from Darktable, and make it a separate, stand-alone application. The process of doing so would be disruptive to users who like the DAM, and provide little to no benefit to the users who don’t use the DAM. The only users who would eventually benefit might be those who want to use Darktable’s DAM with a different RAW processor.
This being an open source project, if an undertaking like that was going to occur, it would more likely happen because someone who wants to use Darktable’s DAM with RT or some other processor decides to own and lead the initiative. It’s much less likely to happen because people who don’t like the DAM want want it excised from the project. As AP complained, DT’s leadership seems reluctant to throw away code if even one contributor uses it.
Speculating here: we would be more likely to see a folder-centric interface thrown into DT in addition to the existing tag-centric interface, rather than seeing the DAM split out on its own.
Yes, there’s a folders view of the tag-centric catalog. I meant something that was more of an analog to Lightroom’s folder-centric approach, which includes management of the underlying files folders. I know some LR users have a workflow that involves moving photos around the filesystem from within the LR catalog interface.
TBH, I am mostly speculating based on past experience, and not hard data, so it is understandable that reasonable people can hold a different opinion. I also write a lot of software by necessity (most of it ends up as open source), and find that independent projects develop faster. It is not that monolithic projects cannot do something, just that it takes longer to get there. And without a lead developer who has a clear vision, people are afraid of culling unused features and doing any major refactoring which would step on someone’s toe.
I fully agree that major changes are disruptive. But sometimes disruption is the way forward. Remember how (some) users took the transition to screen referred workflow.
The one and only true reason for a DAM is to find the images you want to find.
Wether that means micro-tagging or no organisation at all is a personal choice.
In almost 20 years I am now on my 5th major Raw-Editor and the only problems I ever had were when I thought I needed to rely on some database centered application. No matter how you look at it, that database application will be obsolete at some point. But your images will hopefully live much longer than that.
I have since switched to using my own simplified system and it let’s me find images in no time while being very future proof. Flat textfiles for the win.
There is a folder structure
YEAR/PROJECT/Subfolders/
then I fill in a few metadata fields:
TransmissionReference
Country / Region / City
Keywords that describe the content in broad terms (e.g. landscape, mountain, lake, tree, …)
and I have a script that extracts that information per project into a simple textfile each where I can grep through them. Very effective, super fast, pretty much no maintenance. The “database” needs no migration, can not corrupt, etc pp.
And darktable? Used for tagging and editing, but images are usually only a few hours imported, then I remove them all again. If I edit a folder in RawTherapee or with some Adobe App at a customer I don’t have to sweat anything, the system stays the same.
PS: The only problem I still have not solved due to time-constraints is transferring metadata and keywords from one editor so another editor can work with them. Talking about standards.
So the missing darktable feature I would complain about is that dt does not write the metadata back into the plain “Adobe” xmp files for everyone else to consume. One of these days I’ll sit down and fire up that Python XMP Toolkit and get it done outside of dt.
Soon™.
I constantly switch back and forth between the darkroom and lighttable, so the only way a separate DAM application would work for me is if the integration between them were amazingly seamless, and if certain functions of the lighttable were added to the darkroom. For example, copying over the history stack to multiple images is a feature currently reserved for the lighttable. But as someone who uses the filmstrip in the darkroom, I would find it very helpful to be able to copy the history stack directly to other images in the filmstrip without leaving the darkroom.
I don’t know how seamless that could ever be with a separate DAM application, considering I already find it somewhat disruptive to have to exit the darkroom to do it.
I admit that part of my enjoyment of darktable’s DAM features is down to familiarity. I moved over from Lightroom and so I was already used to working like that. Personally, I like having everything in one place, but I know this is a matter of individual preference.
), I store everything in dated descriptive folders and after processing (and after backups run) I delete all images that weren’t “keepers”, keeping only raws, sidecars, TIFFs, edited copies (GIMP, whatever) and since they’re small, exported JPGs. Sometimes I’ll go back and delete TIFFs as well later on to save space.