I was trying to answer a question for someone recently. They send images to clients with a watermark that has the image id from the database. THe clients select images for him by providing the numbers… He was trying to filter in in the collections filter…I could see group id but not image id as an option, and if he was to add that variable to the exported file name you could text search it on that I would guess.
However when I read here…
It makes it sound like you could search the metadata…maybe that is just the file and not data managed by the DT database… I was just curious if I missed something…
I wondered about that but when I checked I had images with different values for group and image ID and others were the same… But maybe in general that would work…
The image id is the row entry in the database image table, so 1 is the first image. The group id is the image id of the group leader. If the image is not part of a group, then the group id is equal to the image id.
I have all kinds of things I want to say about this, but I’ll go with “maybe you should try out your workflow on yourself before relying on it in the real world”.
The real problem is that the image id is an implementation detail and was never meant to be “used” by the user. 20/20 hindsight says maybe we shouldn’t have exposed it as a variable.
Here’s how we can fix this user’s poor choice. I could write a lua-script that exposes the image id as a tag then the user could filter on that.
And actually is a poor way to identify a photo in the long term, as it will change the moment the original database gets nuked or you import it into a new database.
I agree, and really I was just exploring if it was possible in order to reply to his question. Given that background use case what would be a streamlined way to do this…ie create searchable identifier from a series of exported photos to a client??
THanks for your comments Bill…no need for further inquiry…I will let them sort out what they are going to do…as noted by you and others its not a good choice…
What I do to track the original file (for me, nowhere near a commercial setting) is to add the checksum of the RAW file to the XMP file, specifically to the xmpMM:DocumentID tag. This is then transferred to any exported JPG file, and it’s guaranteed to be unique and inmutable because I do not touch the original RAWs.
However it is a bit flacky and manual, as you need to re-import the XMP file after adding the tag, and duplicates do not inherit it automatically. The ID is also not unique between different renditions of the same RAW file.
Your question prompted me to think again about this last point, how could I track a particular rendition of the file? One possible extension of my current system would be to calculate the checksum of the exported image, but this should be done only on the image data as metadata may be changed afterwards. Is there a way to easily dump the bitmap data only from a JPG?
In any case, this is far from being a simple and streamlined approach in general. Probably the best thing would be to generate within darktable an unique ID NOT related to the database, and ideally neither to the name of the files nor the duplicates “title”, so it can be deterministically generated again only from the RAW and the XMP. Maybe the checksum of the RAW file concatenated with the one from the development history, which is then added as a specific ID tag on the XMP file and exported files?
Interesting…thanks for taking the time to think out loud and share your thoughts about various possibilities… I hadn’t really thought about it on that level before…
The checksum approach for the RAW file has the secondary purpose of checking for file corruption and, as I use git-annex, has the nice property of also being included in the filename of the annexed file
It has the same problem as the checksum I use: it can identify the original RAW, but it can’t distinguish between different editions of it. There needs to be some part of this ID related to the development (I propose a concatenation so it’s easy to recover both parts)
(last time I thought about this duplicates didn’t have titles). This might be a path to a reproducible and unique ID.
However I’d like to have something more tied to the exact development state, independent of manual names than can be lost or rewritten with new versions. Is there some kind of checksum of the development state already available? I see in the XMP some tags related to the full history, history_auto_hash and history_current_hash. What do they hash?
