TL;DR: darktable gets better over time, so version-specific defaults
have a chance to get better, too, right? Why force *current* defaults
even for unedited unexported files?
Le 21/11/2016 à 18:47, Roman Lebedev a écrit :
If we do not write XMP when doing any export based on raw data (not counting
embedded thumbs), next time we do the same export, the result may be
different. And modulo bugs, that is*not* the intended result.
Good point. In most cases, the user will edit somehow before exporting,
writing XMP so we're safe.
In some cases the user may be satisfied with defaults *and* expect exact
reproducibility.
That's a reason to say that exporting a picture should trigger
unconditional write of a XMP sidecar file.
if ( (no XMP file already exists) && (image has no tag "changed" or
"exported") ) { skip
xmp creation };
So what happens if you open image and then immediately close it?
In that case it's not "changed", it's not "exported".
So, it's a case of picture *viewing*. I see no reason to generate a XMP
file with parameters *specific to current version of darktable* just
because I happened to view it with *that* version.
Concrete case:
* You have a dir full of RAW. To figure out which one you want to edit,
you open directory in darktable.
* You find and edit *one* picture, export it. XMP sidecar for that
picture is definitely needed.
* Now, consider all other files. What's the reason to generate XMP files
for *all* those files? Is the XMP generated *now* better than a XMP
generated by a future, improved version of darktable?
I'm trying to understand your position. Do you consider that whatever
behavior *current* darktable exhibits on first it sees a picture (not
even editing or exporting it) should be cast in stone and frozen in
time? Or did I misunderstand ?
Thank you for enlightening me.
Sincerely,
--
Stéphane Gourichon
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to [email protected]
