I did not find a way to save sidecar files with a name different from the original picture. In my opinion It could be useful if I apply differenr filters to the same picture and to remember what kind of post processing I applied.
I know that I can duplicate.
An example could be dsc001_BW.xmp, dsc001_saturatedcolors.xmp or dsc001_luma.xmp.
Any suggestions is appreciated.
In normal use, you donāt even see the sidecar names. So I donāt quite see where using arbitrary names would be useful
Also, the whole use of sidecars within dt is based on the fixed naming scheme. Doing what you suggest would, at the moment, break almost all uses of the sidecars. So you cannot change the name to an arbitrary one. And the use of sidecars is optional, you can use only the database.
Depending on how many different processing variants you use, you could use tags or colour labels instead of sidecar names? And you can add a comment to duplicates in the darkroom (even if thereās only one duplicate of a file).
As an aside, dt uses the original extension in the sidecar names as well, to allow having xxx.arw and xxx.jpg side by side, with (a) sidecar(s) for each. Messing that up would potentially also break things.
You can use the version name variable to add to the name of your exported JPG Then just name your duplicates to define what that label is going to be when added. Also your JPG contains the sidecar info so you can just load it as a side car in place of an xmpā¦So if itās named to identify the edits you would have a tracking system
@rvietor @priort
I understood the DT logic now. I just switched to DT so Iām a newbie.
Iāll do some tests to understand better.
Thanks to all for suggestions.
Mine is only one way. But itās pretty easy. When you create duplicates they are assigned a numberā¦if you click under that you can add a name. That is assigned to a variable that you can use in the export dialogue called $(version_name). So you can automatically have that added to your export file name and dice the JPG has the xmp data in its metadata then you can later use it as a sidecarā¦so this might work for you in most case
2 Likes
@priort
Great ! Very useful ! Your suggestion answers my question.
But that is not all ( 
): is there a way to set a duplicate in read-only ?
I mean disable any changes (of the history). I happened to have selected another duplicate by mistake and changed it.
Iām looking a way is to have an export that corresponds exactly to an history.
Since you have developer in your name, perhaps you know how to use git or another revision control system. XMP files are plain text. I check my XMPs into git so theyāre versioned and my change history is there. I also check my raw files into git annex, but that is a story for another day.
2 Likes
Good suggestion. Another way would be to alter file permissions. But I prefer the git approach.
True !
Good suggestion.
Now Iāll investigating how keep linked xmp, exports and original raw files.
I donāt know git annex.
At work we are starting use āregistryā in GitLab, but It seems like annex in git. (I donāt know)ā¦
If you are on WIndows you can use a little program called Autover to watch your folders for xmp and version them in a back up location of your choiceā¦if notā¦recall what I said if you export an edit as a jpg the history is save with itā¦so you can simply apply that edit to a raw using that jpg and it will apply the edits you made to make that raw fileā¦so really no need to mess around renaming them except in DT be sure to give your duplicates names to be able to use the version name variable as part of the exported JPG nameā¦
The problem with making the xmp files read-only is that darktable will write the changes to the database anyways, so you end up with a conflict. If you catch the error fast youāll know you need to overwrite the database with the xmp version, but after some time youāll probably forget and start wondering which is the correct version.
Yes, true, unless you start darktable with --library :memory:
Are you looking for a possible feature in dt where a preference setting would turn on some extra processing, namely, when you output an image, dt would also output a copy of the XMP named the same as your image. You would then have a free-standing independent record of your edits.
@RawConvert
Yes, It is. I donāt have enough DT knowledge to say whatās best, with less impact.
Another option could be a simple (I believe) flag that put a duplicate in read-only.
It is like freezing a state of work.
In this way, after a duplicate export that satisfies you, manually set the read-only flag to true.
After that you have a history that matches the export.
Itās embedded in the JPG so it really overkillā¦
I donāt much like the history being in the jpeg. Seems odd someone has gone to all that trouble to design a compact file, then you go and stuff data in it which is irrelevant to most people who see the image! If I send someone a box of chocolates, I donāt enclose a map showing the route I took to the shop where I bought them! Some might even argue having the history in there is a privacy concern? And correct me if wrong, but the jpeg history is not 100% reliable because tags can be too big.
@Ric_Developer , I can see setting read-only is more secure, however dt does not access XMPs with a name other than āimage fileā.XMP (unless you explicitly tell it to, e.g. loading an existing xmp onto an image file) so perhaps you might be worrying too much about this?
Storing the history stack in the exported image file is optional, as is the use of sidecar files. So all that can be set according to your personal preferences.
As for the size, according to the manual:
āEntries in XMP tags can get rather large and may exceed the available space to store the history stack in some output files on exportā. Thatās probably which is why there is an option to store them in a compressed binary format.
Maybe yes. Iāll try to find the best suitable processing flow for me.
In general I like sidecar files, but not for all files even if not edited. So I disabled āwrite didecar for all imagesā.
Iām doing some tests.
In the next version of darktable you will be able to choose only to write sidecar files when you edit an image, rather than on import.
Great !!! 