Today I learned a lesson I want to share with you.
I got angry with darktable because of loosing my manual metadata entries on images.
When taking images with vintage lenses, that of course provide no lens information to the camera, I like to add the lens type and f-stop as metadata in the field “notes”. I frequently change computers so I keep all my images on portable SSD disk and after opening the images on the other computer (separate dt database) all metadata was gone.
Lesson learned:
Editing metadata does NOT write an XMP file - if you choose to create XMP files only “after edit” in darktable preferences, storage section!
I chose this option to save space and files on the disk for unedited RAW files.
I had a similar experience during holidays. I took my notebook with me to edit some photos already. At home, I copied over the whole folder with the raws and xmps and found out that all tags that I had given to the photos were gone. The editing steps were there though.
Indeed, setting “after edit” solved that: darktable 4.2 user manual - storage
I can’t fully understand what actually took place here.
The default value for creating xmp files is on import. According to the manual once xmp files are written, which you inform have been created, “they will subsequently be updated each time you edit or add a tag to the image”.
Was the problem that you hadn’t checked off “look for updated XMP files on startup” on your home PC?
Now that you say it, it indeed does not fully makes sense.
I just tested on my laptop - which still has the setting on import. If I add some tags, they are immediately written into the XMP. Maybe it was a problem with a previous version of darktable only? IIRC the problem was that there was a setting that may hinders tags from being written in the XMP files, as they were really missing from the XMP file. I had this problem in 2022.
The space savings from using after edit instead of on import isn’t what you think it might be.
I use on import. From 12/23 to 5/24 I shot 80,000+ images. The total space taken up by the XMP files was the same as what 16 raws take.
after import is only useful for retaining a copy of your edits. Using it as a last resort to restore your database doesn’t work as evidenced by the numerous issues raised when users lost their database and found out the hard way.
I’ll trade the space of 16 raws for a more reliable backup.
You are right, Bill! I changed the setting in the meantime. Although you need to count not only the visible filesize shown in the explorer but take into account the blocksize of the filesystem. In case you use a large disk of 4 Terabyte or more your filesystem will be formatted with a blocksize of maybe 64k instead of 4kB and then you might loose the equivalent size of at least 100 raw images!! (out of 80.000)
Interesting philosophy - considering raw as inviolate even if incorrect …
for example, I was just able to enter the Takumars’ Model, f-number and FL into the raw file for the above. Of interest to some maybe - especially to those who might shoot many raws at a time … but with the wrong WB, date, etc. na-ni-na …
The sidecar file is there to hold additional data. Artifacts are often incomplete
If the tool you’re using to alter your raw file, or the underlying system, has an issue or bug, then you’ve damaged your raw file. Hopefully there are backups!
Understood. The implication is still that raw files should not be altered. Does darktable make that necessary or is it just your opinion?
Straw man argument - anything can damage “your raw file” not just the tool and … yes … I altered a copy of my raw file and verified that it wasn’t “damaged”.
The point you missed is that trying to alter your raw file leads to a way higher chance of it being damaged than just using the sidecar file. Not that “editing your raw file will absolutely damage it.”
Now comes the spin: “trying to alter your raw file” - as if that were fraught with danger and at all difficult. If an old man like me can do it, it is highly possible that anyone can.
Can we leave it that your opinion and possibly that of others is “raw files are sacrosanct” and that I disagree?
Of course this is true - but there are plenty of tools to do this if you or anyone want to do it.
darktable developers decided this app not to be a further exif editor.
If you provide a tool to manipulate raw files then you must take care to avoid messing up that stuff. That implies effort that can’t be spent on darktables core functionality. But the latter is why darktable developers spend their time on the project
Incorrect? That depends on how you look at it: the raw registers what the lens told the camera. In the case of pre-digital lenses, that is “nothing”.
In addition, adding those data later means that the chance of errors is larger (do you remember which lens was used, which settings you used for the lens, and do you always spell the name the same?), and wrong info is worse than no info…
Oh, it’s possible, even quite easy, to alter raw files. But if even a well-known camera brand manages to provide a raw editor that damages its own raw files, I prefer to err on the side of caution…
You mean it may not always be possible to restore the database from the sidecar files alone, independent of the setting I have for write sidecar file for each image?
I thought that the database was just there to have faster lookup…
(out of 80.000)