With XMP files creation on import is IMO mandatory, as only the XMP file contains any modifications at all, sice darktable does not and will not ever modify RAWs or processed files. You can totally disable xmp generation and rely only on db which has a downside of possibility of failing when needed. Now - xmp file doesn't only contain "edits" as in graphical changes to the image - it's also all the tags, metadata, geolocation and everything else. And since on import darktable adds autogenerated tags, the "modification" is there already, so Patrick was correct.
As for implementing the feature yourself, meaning "lazy xmp creation" or "only when important* stuff changed" *="depends on definition of important", you should start where all devs start: https://github.com/darktable-org/darktable then simply browse PRs, test them, see the changes they make, leave comments, browse issues and try to tackle them by creating small prs and then go with your feature. Have fun and remember to always try to make darktable better for all, not just for yourself :) sob., 20 lut 2021 o 10:09 Bertwim <b...@xs4all.nl> napisał(a): > Sorry Dimitry, but how does this help me implementing the export of > xmp-files of modified images? > > Regards > Bw > > On 2/20/21 9:49 AM, Dimitri Gathy wrote: > > In the module import, there is "parameters" & the "ignore jpegs". When you > export, you can choose the destination. Read the manual. > > Le sam. 20 févr. 2021 à 09:43, Bertwim <b...@xs4all.nl> a écrit : > >> I might do that, but I am considering implementing it myself. >> I am not very familiar with the darktable internals (yet), Perhaps >> somebody from this dev-list kan give some suggestions how to tackle the >> problem. >> >> >> >> Regards, >> Bertwim >> >> On 2/20/21 9:31 AM, Martin Straeten wrote: >> >> Then you may file a feature request at >> https://github.com/darktable-org/darktable/issues/new?assignees=&labels=&template=feature_request.md&title= >> and >> be patient until someone implements it ... >> >> Am 20.02.2021 um 09:23 schrieb Bertwim <b...@xs4all.nl> <b...@xs4all.nl>: >> >> Hi Martin, >> >> Sure, but that is not what I am looking for. I don't want unnecessary >> being being generated. >> >> Kind Regards, >> Bertwim >> >> On 2/20/21 7:31 AM, Martin Straeten wrote: >> >> You can use the collection filters just to display edited images using >> darktable related tagging >> >> ___________________________________________________________________________ >> darktable developer mailing list >> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org >> >> >> Then ctrl+a and save xmp file >> >> >> Am 19.02.2021 um 22:46 schrieb Bertwim <b...@xs4all.nl> <b...@xs4all.nl>: >> >> Hi, >> >> My camera creates an image both in raw format (Nikon, nef) and a jpg. When >> the camera-produced jpg is good enough, I just want to keep it, leaving it >> untouched by DT. No xmp-file needed or even desired. For the others >> pictures, I use DT to process the the raw image and export a new jpg, >> overwriting the original camera-produced jpg. For those pictures I want the >> xmp file. >> In other words, I would like to have an xmp file *only* for those images >> that I have actually edited. No no xmp-files for images that I have not >> touched/edited. >> >> I don''t think DT is currently providing this in a convenient way. It can >> write xmp files automatically for *all* images, but that is too much. >> It is possible to achieve this selective xmp-export manually by first >> selecting in lightroom the 'untouched' images, inverting this selection and >> then choose "write sidecar files' in the history stack menu. This however, >> is cumbersome, tedious and error prone. I am looking for a more robust and >> automated way to achieve the same. >> It would make sense I think to write an xmp file together with the export, >> So I was thinking if I could add this option to the code. >> >> I would value some comments or feedback if this option would be worthwhile >> to pursue. >> >> Kind Regards, >> Bertwim >> >> >> >> ___________________________________________________________________________ >> darktable developer mailing list >> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org >> >> >> >> ___________________________________________________________________________ >> darktable developer mailing list to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> >> >> ___________________________________________________________________________ >> darktable developer mailing list to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> >> >> >> ___________________________________________________________________________ >> darktable developer mailing list to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > -- Pozdrawiam, Hubert Kowalski ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
