Regarding the workflow I don't see any problem since DT automatically tag the images exported so you can set a filter on the tag 'exported' to exclude them of the displayed collection if you want.
Regarding the xmp sidecar I think they are useful even if the image has not been exported because sometimes I work on an image without exporting it immediately so the sidecar keep my current work. But I agree that DT could not generate a sidecar until the image is not opened at least one time in the darkroom. But I cannot see any benefice for that, I prefer rely only on 'exported' and 'changed' tags. BTW I opened an issue related (# 10460) because currently DT set the tag 'changed' when you exit the darkroom whithout exporting even without any change in the history. 2015-05-26 20:50 GMT+02:00 Bertwim <b...@xs4all.nl>: > Pascal, I think you completely misread my posting (see also below): > > Moreover, I cannot understand why it is suggested (implicitly) that it > is useful to have xmp files around > that have in essence no new information: they are directly generated and > associated with > images that have had no modification via darktable. > For the very same reason, they are not needed to regenerate the database. > These "untouched" xmp files are just serving no purpose. > > Worse, as I indicated in my original email, they make certain workflows > unnecessary complex and error prone, > which I think is unwanted from a usability perspective, > > > Regards, > Bw > > > > > On 26/05/15 18:37, Pascal Obry wrote: > > Le mardi 26 mai 2015 à 18:29 +0200, Bertwim a écrit : > >> Don't you think it would make sense to (automatically) couple the > >> writing of the xmp-file to the *export* of an image? > > No, because in this case you do not have the safety of the .xmp in case > > your DB is corrupt. The DB is fine for fast access but if it got corrupt > > you *loose* all your edit for *all* your pictures. That's just not an > > option to me. > ON THE CONTRARY: this will ensure that you always have an xmp file > available, when it is meaningful. > As opposed to the situation where no xmp file is created, which currently > is > veru much possible in Darktable. > > > > >> Or at least have this option? It would be a great help in the simple > >> workflow where the original images (raw,jpg,both) are loaded into > >> darktable, > >> some of them are "edited" with darktable, after which new copies of > >> these "modified" images are exported. > > As already stated you have tag for this. > > > >> The fact that, when xmp files are present, darktable can just recover > >> from losing the database is a great, great, great feature. > > Right :) > > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Darktable-users mailing list > Darktable-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/darktable-users >
------------------------------------------------------------------------------
_______________________________________________ Darktable-users mailing list Darktable-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-users
