Context dt 5.4.1 on ubuntu 24.04
Typically, i use exiftool to rename my images before importing into dt. (why? it sorts the files correctly by date time before renaming which makes a difference when importing batches from different cameras with different filenaming schemes.) This works great except for twice a year when the fricking “daylight savings” change occurs and my stupid cameras can’t figure this out. Usually I figure this out before doing any editing and just delete from dt and use exiftool to patch up the time shift and then reimport. I do this because I want the file names to accurately reflect the time the photos were taken. FWIW, the pattern is YYYYMMDD-HHMMSS-xxxx.ext
Problem
Today, I had done a lot of editing before deciding I needed to import the GPS tags, which is when I discovered the time discrepancy. Ok. I used dt’s time offset in the geotagging module to fix that, and reapplied the GPS data. That’s all good. But now the file names are off by an hour. Ok, let’s try the rename module. Nothing happens because apparently the image timestamps haven’t really changed according to dt, and this is reflected in the image information module.
Fumbling for a solution
Delete all the files, fix files with exiftool, and re-import. Hours of editing down the drain.
Same as above, but hand rename the 200+ .XMP files to preserve my edits. grrrr
What is the ‘refresh EXIF’ thingie in the actions on selection module? I could use exiftool to modify the timestamps and then refresh EXIF to reread them, then maybe rename would work. Nope. doesn’t work. What is that supposed to do, anyway?
Only viable option seems to be to get exiftool to rename the .xmp files which it can do, but, for now it’s leaving out the JPG|ORF part of the name: i.e. .JPG.XMP → .XMP. I may have to script this part, which I’m loathe to do, but, oh well.
So, can dt do this kind of salvage operation? If not, it would be nice if it could. If ‘refresh EXIF’ actually reread the image exif timestamp data and applied it, then I think it would work.
this is similar to another recent topic about handling of timestamps
Timestamps are tricky, because there are so many of them. So if you change the “wrong” one, darktable may not see the changes, because it uses the other time stamp…
In addition, darktable doesn’t write to source images, so the timestamps in the raw files will not be changed. That also means that your geotagging only exists in the database and sidecars.
As you can adjust the filenames, including the sidecar names, with exiftool, with the only issue remaining being the sidecar extension, that would be scriptable. I’d go for a script that runs exiftool on a file, and immediately renames the sidecar (in case you have/get both a raw and a jpg with the same name). Depending on what the “xxxx” in your naming scheme is, you may have to move each file to a temporary directory to prevent name clashes.
If I understand your system correctly, you use exiftool to correct the timestamps and rename the image? If that’s the case, “actions on selection” doesn’t see the changed files as the name is different. So darktable correctly refuses to change anything.
There is a time shift lua module, you could use that and then darktables own file-renamer to fix the files. That’s how I did it yesterday ;-). (fuck daylight saving time).
contrib/image_time allows you to adjust date/time as well as synchronize image times between 2 cameras.
You can select the images you want to change and then add or subtract an hour. The script only updates the date/time in the database and doesn’t make changes to the images themselves.
Not quite. My first attempt was to use exiftool to update the image timestamp w/o renaming, and then use ‘Refresh EXIF’ to reread and apply it in dt, since it says “update all image information to match changes to file”
If the behavior won’t change, the ‘help’ text for refresh EXIF , and maybe docs, should be changed to indicate that it really doesn’t reread timestamps in the source files. I still don’t understand what it does or should do.
this is insufficient for me, since I want the image files to have correct timestamps.
Perhaps I could have done this and followed @mino 's process and then used exiftool to actually modify the image timestamps. As he said: ‘fuck daylight saving time’
FWIW, I ended up deleting the images from dt, patching with exiftool, and redoing the edits. I tried saving the xmp files, but that didn’t work or i couldn’t figure out how to make it work.
Bottom line: I’d like a dt that could handle this internally because it has all the information about what needs to change. If I can tell dt to delete an image from the filesystem, I should be able to tell it to modify a critical bit of metadata.
But, as said already, darktable will not write to image files (except on export, of course). So any changes to metadata, including timestamps, will never be written to the image files.
That has nothing to do with technical capabilities, it’s a design choice (and, imho, a good one).
Note that the same goes for geolocation data added in darktable (EXIF has tags for GPS information).
And while culling (i.e. deleting) images is part of a normal workflow, changing camera metadata is a lot less common. It’s also (again, imho) something to avoid, esp. with raw files (as errors can have unpleasant consequences with no way back). And when/if tracability becomes more common, it would break that tracability (as it will change the checksums used for that).
Because he uses the information as a basis for sorting and renaming files, including merging images from more than one camera.
I’m thankful that I don’t have to do anything like that: I use only one camera and am happy with the camera filenames. But I do read the exif data to change the last-modified dates in the file system, so they express the date and time of the click, not the subsequent post-processed output. This is very simple, and does not affect dt’s relationship with the raw data
Why do you want to do that? The “date and time of the click” are in the metadata, not in the file system. The latter only registers timestamps related to the file, not the image. And changing the modification date/time can throw off programs that use that information to decide if a file needs to be backed up, reread, etc. (I think darktable uses the modification date/time of sidecars, and perhaps jpegs, to decide if they need to be reread on startup).
I could argue this, but I get that this doesn’t seem like a core feature for dt, and there wouldn’t be a clear place to draw a line between things you would or wouldn’t change in a file, if some bits could be changed and others not. But this particular issue will continue to occur until cameras are all connected to cell towers or GPS signals, and it’s really annoying.
The bulk of my photos end up on iNaturalist, and I often use two or three cameras (including my phone) when out botanizing. If the photos from one camera are an hour off, then they get separated from the other photos of the same subject both at culling/processing time, and when uploading to iNaturalist, when I need to grab all the related photos at once. And, iNat uses the EXIF timestamps for ordering observations, so even if the photos are all from one camera, I don’t want them off by an hour - or more, considering the time I forgot to reset my timezone and started taking photos in Europe: camera photos were then off by 9 hours from phone photos.
Finally, as @Thad_E_Ginathom mentioned, my primary DRM is the file system, so I can find stuff by date and find other stuff close in time to something else by the file name.
I think there is an issue with the photos having multiple timestamps. You are talking about the EXIF Tag DateTimeOriginal, correct? Then I get your point and take the same approach.
If you only change the database timestamp and not the image
darktable can sort by the database timestamps (capture time, import time, etc.)
Images can be renamed on export by using variables such as $(EXIF.HOUR)
I use 2 cameras and at the start of a shoot I hold one in each hand pointed at the ground and trigger them at the same time. Then using the image time script I can select the 2 images, calculate the difference, and add or subtract the offset to one camera’s images. I shoot sports so I’m often swapping cameras depending on lens, distance, action…
I could rethink my workflow once again, but your method leaves the source and derived files disconnected except in dt. Luckily for me. I’ve never needed as fine-grained correlation as you