Well Geeqie does not attempt to show me a list of directories I used last time around and which may or may not have been moved/deleted. Geeqie just helps me find the files I want to see now.
Fair enough that you want Darktable to import and maintain a list of directories/files you worked on last week, but it should be able to handle other types of workflow. Like for example how most other programs handle files …
Most of all since importing complete directories of files into Darktable still does not give it a speed advantage in displaying files over Geeqie or other programs.
Yeah I know what the skulls mean, but I really don’t need a program patronizing me by using two thirds of my display to get that point through.
You can run darktable with --library :memory: and it won’t store any images to the database.
Its about convienence, not speed. I like to see what I edited last.
Most programs (including dt, depending on your settings) show you the raw file’s embedded thumbnail, that’s why they’re fast, they’re not processing any of the raw data.
Its not patronizing to know that images aren’t available. There is a feature to make them a available (local copy) and then you can filter your collection down to what is available locally.
I def went an indicator of when images in my library are not available, as that likely signals a serious underlying problem.
Just different use cases/user preferences. As I read somewhere, in relation to photography I think, trying to please everyone leads to nothing but compromises… I suspect this applies to software too.
Different programs, different aims, different approaches. Somehow I guess you don’t like the editing options Geeqie provides (otherwise, why use dt?).
Darktable made certain design choices, one of which is assuming as default that images are on a permanently available medium. A way to change that default behaviour was given (“darktable --library :memory:” or change the corresponding entry in the configuration file).
When you keep the default behaviour, you are warned when images are not available as you should be: dt comes back to the film roll where you exited the program. A film roll is not just a synonym for a folder, but can be the result of a more or less complex search you set up. That film roll was not empty when you last exited dt. Now it is, so dt tells you “I have those images in my database, but they are not where I was told to expect them”.
Again, no. Copy-local exists. You can use external or network disks as your primary storage for raw files. OP also had something happen to their cache, or else they’d see thumbnails. I used an external disk for several years and didn’t run into this.
Here is my simple workflow involving Darktable/Ansel and digiKam (only for DAM). My main folders are:
Photo\1 Process - I put unprocessed files there (mostly RAWs, but also unprocessed TIFFs from a scanner), organized in Year\Month-Day-Event folder structure. This folder is for Darktable.
Photo\2 Export - “Final” JPGs exported from Darktable (or Affinity etc.) - this folder is for digiKam only.
I export files from Darktable using the path below: $(FILE_FOLDER/1 Process/2 Export)/$(FILE_NAME)
This simply replaces “1 Process” with “2 Export” in the folder name. This way both folder have the same file structure inside.
So, for example “1 Process\2023\08 25 Trekking\IMG_2995.cr3” is exported as “2 Export\2023\08 25 Trekking\IMG_2995.jpg”.
After exporting a photo I add tags in Digikam (inluding face recognition), all data is saved to XMP files. I can run both programs at the same time - they don’t overwrite each other’s data.
The best part - whenever I decide a photo needs some tweaks (which happens VERY often - I’m still learning ), I can re-export it from DarkTable (I set “On conflict: overwrite”). The XMP file created with digiKam is preserved, only the picture is updated.
Bonus: if I decide to try another DAM solution, I won’t be held back by the digiKam’s database because all tags are stored inside sidecar files.
Perfect sense and I have almost exactly the same workflow myself.
The only issue is re-tagging after tweaking. Each new export from DT needs to be retagged in DigiKam, but if the photo was worth redoing, its only a small hardship.
My experience is different. The few times I had to add keywords in dt, digikam read the new keywords.
But I do remember I had to change the order in which digikam used xmp tags: in the digikam settings for metadata, you can set xml tags will be used for reading and writing, and in which order they will be used for reading.
Sorry, I need to be a bit clearer: Digikam does seem to pick up any key words defined in Darktable, but my workflow is to do all my tagging in Digikam.
I have a couple of thousand tags in a Digikam hierarchy and add another 50-100 each trip. The Digikam tagging facilities are reasonably flexible these days, and I can do bulk alterations fairly well, so it meets my needs.
So my gotcha scenario is as follows: Raw Image0100.CR2 is processed in Darktable, given a provisional star rating, and exported to Image0100.jpg . I view the jpg in Digikam, tag it appropriately, revise the rating if necessary, etc etc. I then compare Image0100.jpg to related images, and decide whether the raw file Image0100.CR2 is worth more detailed processing (or I come back to it months later armed with the latest and greatest Darktable modules). There does not appear to be an easy way to import the metadata from Image0100.jpg into the XMP file for Image0100.CR2 (correct me if I am wrong)
After reprocessing I again export , this time writing to Image0100a.jpg . I compare the new jpg to the old to see if I really improved it, and if so I have to copy the metadata from Image0100.jpg to Image0100a.jpg . This is just a few keystrokes, but still. . . .
Hope that’s clearer, and if I am missing something, please say!!
If you can tag the raw file with Digikam before you edit (or at least export) the file you save some work.
If you set up Digikam to follow the correct standard filename.xmp and export to the same folder as the cr2 the .xmp file should technically be valid for both cr2 and jpeg files and Digikam should treat the xmp as metadata for both files. How darktable handles this I don’t know. Might take some settings tweaking of both dt and Digikam.
Both digikam and dt handle sidecars named <base>.<ext>.xmp just fine. So just using the default scheme for both just works. In addition, digikam can read and write the metadata from a jpeg file correctly as well, so no need for a sidecar there.
And, using the same sidecar for both formats means you have to use the same metadata for both. That may not even be what you want at the end of the day (e.g. for licensing).
The point was that @Aliks issue is solved by using the standard xmp filename convention. It was a solution to their specific problem (but also good practice and this issue was probably the rationale behind the standard).
With filename.ext.xmp you need to always re tag the exports, or the raw. With the proper xmp convention you only need to tag once because it applies so all files with that basename. But as I mentioned this relies on exporting to the same folder and writing .xmp when tagging. If you use a different folder structure it won’t work and you really need to tag the raw before export.
You can always embed specific metadata in the jpeg anyway. Or rename the file (add suffix) if the content changes from crop etc.
@Aliks : Right, I see what you mean, and that’s indeed not easy to solve. Then again, as you (have to) change the basename of the jpg, neither sidecar naming scheme will help.
What might help is changing the rating in darktable before export. Then, if you reread the metadata in digikam, that will be read (and rereading can be done for a complete album).
If you have to change more than just the rating, or if you’re using dt’s duplicates, I don’t see an easy solution.
But dt reads the standard xmp file name convention right? Or am I misremembering this. If I’m not the standard xmp filnaming will work. When you export Image0100a.jpg you can have dt re-read the .xmp file before you press the button right? All files will then be in sync.
Yes, but that’s on file import. I believe you’d need to reimport your raw file to trigger that sidecar file reread. It is not a workflow I’d generally recommend for darktable.
Ah bummer, I was looking around for a way to “re-import” a file but couldn’t find one. So if the “look for updated xmp file on startup” checkbox only deals with filename.ext.xmp files we’re out of luck.
The issues comes from tagging the exported image0100.jpg rather than image0100.cr2 so subsequent exports lack metadata.
Another option for @Aliks is to use the group by filename feature in Digikam. Then files with the same basename are treated as one (much like the xmp filename spec.) . So that the parent gets tagged at the same time as the child. Geeqie does this as well but in a much more transparent way.
), I can re-export it from DarkTable (I set “On conflict: overwrite”). The XMP file created with digiKam is preserved, only the picture is updated.