Le 20/11/2016 à 19:24, Tobias Ellinghaus a écrit :
That is not feasible as we rewrite the XMP files all the time. Not just when
you edit the image in darkroom.
IMHO this behavior pops up too regularly in discussions.
# Context: user feedback + usual reply
This is from memory, I might be wrong.
User: "darktable (writes an uninteresting XMP file | clobbers
interesting XMP file) for *each and any* raw or jpeg file that it
encounters at startup. This (slows down|clutters directories|loses minor
information|loses important work|feels wrong)."
Reply (from memory): (due to the way we organized things|we just write
XMP at some points in time and which causes overall behavior just like
you wrote|it's too difficult to change that behavior|just remove them if
undesired|make dir read-only)
Spirit of Free Software whispers : "Use the source Luke."
# Zooming out to get the big picture
From an outside perspective, current behavior still doesn't feel right.
From a functional point of view, there's no good reason to write a XMP
file for a file that was not even opened in darkroom.
Sure, darktable has default processing options, and might use them to
display thumbnails (in some configurations).
But by definition these options are *generated defaults*, so there's no
point in saving them.
Saving them "pins" those default to the particular version of darktable
just run, is there added value ever in that?
# Related information
Does current code causes an inclination for bugs like this one? Bug
#10012: Darktable overwrites existing XMP files
<https://redmine.darktable.org/issues/10012>
Also, option write_sidecar_files is not the wished behavior, as XMP
files are definitely useful when they contain not only generated
information, cf. 8.2. Core options | user manual | darktable
<http://www.darktable.org/usermanual/ch08s02.html.php>
# Guessing an implementation
Quick look at ./src/common/image.c void dt_image_write_sidecar_file(int
imgid):
> // TODO: compute hash and don't write if not needed!
Darktable *already features some tags "changed" and "exported"* in
database, searchable with the "collect images" structures filtering module.
Given the expected semantic of a "changed" tag, it looks efficient,
simple and natural to write something like:
if ( (no XMP file already exists) && (image has no tag "changed") ) {
skip xmp creation };
That way, XMP indeed gets created when relevant.
# Benefit and conclusion
Current implementations feels like darktable has "dirty hands" or goes
"like a snail/slob/slug": wherever it goes you see its trails that you
have to clean if they're undesired.
* With new behavior, user can open in darktable any dir (USB key from a
friend, whatever) and not clutter it.
* Only edited pictures (if any) will get a sidecar file, which makes it
easier to spot them e.g. for copy-paste back in external file manager.
* Opening wrong directory will not clutter it.
All those use case happened to me. I'm not covering all cases for the
sake of brevity, but I don't get why this was not approved earlier.
(1) Can a fellow savvy darktable wizard elaborate/explain?
(2) If someone offered a clean patch performing this exact change "just
opening a file does not create a XMP, an edit causes it", would you
merge it? If not, can you explain the rationale?
Thank you.
--
Stéphane Gourichon
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to [email protected]
