On Mon, Nov 21, 2016 at 8:19 PM, Stéphane Gourichon <stephane_darkta...@gourichon.org> wrote: > 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 That is not true, see more detailed reply later on. > clobbers interesting XMP file) ??? >for *each and any* raw or jpeg file that it encounters at startup. Only if "don't use embedded preview JPEG but half-size raw" setting is enabled. > This (slows down If writing one XMP slows down your machine, how are you using DT on it? >|clutters directories Well, disable XMP altogether then, or ls -lah | grep -iv .xmp$ :) >|loses minor information|loses important work Care to elaborate? Unless you enable crawler, and make sure to *never* have more than one program that might modify XMP opened at the same time, there should be no loss. >|feels wrong)." So is editing raw files (read: editing the files, the metadata in them), yet people does not understand it :) > 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. Yes, there is. > 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? https://redmine.darktable.org/issues/10345 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. > # Related information > > Does current code causes an inclination for bugs like this one? Bug #10012: > Darktable overwrites existing XMP files Bugs happen, that is the nature of the code :) > 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 > > > # 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" So what happens if you open image and then immediately close it? If you export it, and then thing like https://redmine.darktable.org/issues/10345 will happen, and you export it again, the two exports will be radically different. That way, dt's history stack will no longer result in the same export every time (* currently, it still does not, but that is a bug) >, would you merge > it? If not, can you explain the rationale? (this mail is in dt-user) Nope, i would not merge it, because then i'd have stale commit in my git history, and i would have to workaround it each time i want to push something upstream. > Thank you. > > -- > Stéphane Gourichon Roman. Also, almost, tl:dr; > ____________________________________________________________________________ > darktable user mailing list to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
