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.
Occasionally this works but in my build there are a few weird things that happen if you do it… So if I select a group of images in a row the first time I do it then they all will display the pasted history stack. But after that it is like multiple selections don’t clear. The original images stay gray and selected and the new ones are added. Also sometimes it appears esp if I select non sequential images that only the first one changes but if you go to the others the history pointer is not updated to the top of the stack from the pre paste position . The extra steps have been added. If you manually move the pointer up in the stack then you can see the data was pasted. It seems to behave a bit hap hazard. And the interesting thing that happens also is the cached images in the film strip can get out of step. When you are on the image the preview and the film thumb can match but when you advance to the next image the film thumb can still be the one that you created before with the paste even though you revert it. I was playing around by simply pasting an instance of CC to make images BW so it was easy to see if the paste was effective… This is really hard to explain as a few things seem to happen. I may just make a short video to demonstrate it… But it does seem that there is the potential to so this in darkroom but on the build I have its a bit erratic at the moment…
You mean history stack copying in the darkroom with the filmstrip? Interesting if that’s in the dev builds.
But the filmstrip is definitely erratic, even in the stable release. It often jumps to a different place other than simply advancing to the next image. You also have to be careful where your mouse is hovering. I wish that feature could be turned off because I’ve more than once applied a style to the wrong image just because my cursor was resting on a different image in the filmstrip.
Ya it can work and then there are those weird things I tried to explain. For example the image that had the CC mono preset applied by pasting in darkroom and selection in the filmstrip would then seem to retain that. So resetting the image to color didn’t help. So if you then scrolled to that image the preview and the thumb in the film would be color but when you advanced to the next image the filmstrip thumb would for the image you just left would go to monochrome… so it wasn’t refreshing or it seemed what was being called to display in the film strip was different depending on if the image was the active one or it you had moved to another image… I’ll see if I can repeat and summarize in a very short video… but having said that it does seem to work on occasion to this could likely be cleaned up… also maybe its only me that see’s this…