Am 27.07.2015 um 04:25 schrieb Chris Siebenmann: >> On Sunday, July 26, 2015 18:21 Chris Siebenmann wrote: >>> I don't have a useful answer in general[*], but there is a relatively >>> lesser known darktable feature that may be helpful to you. Darktable >>> normally saves a copy of the XMP in the generated JPG file and it also >>> supports reloading the XMP from this copy. This means that at least in >>> theory you can recover the exact settings used to produce any JPG (and >>> then use them as a basis for further development). >> >> The dt jpg information poses an interesting question for me. I do not >> make jpgs or other output files unless specifically needed. I simply >> rely on the integrity of the raw+xmp set. Is the general feeling that >> a jpg 'security' file is important? > > This is probably specific to my workflow, but I generally don't > consider a RAW file really processed to my satisfaction until I've > generated a JPG, looked at it outside DT, and decided I'm happy with it. > At that point the JPG's embedded XMP is a record of how I got that > particular result, even if I later go back and try other options on > the RAW. > > My approach wouldn't work for people who process and re-process without > generating JPGs; then you're at risk of history loss and need some other > method of dealing with it. >
I once suggested adding the option of a virtual "write protected" flag to image duplicates. This flag could be handled in the database. In case such a "write protected" duplicate gets touched (history stack item added) a new duplicate would automatically be generated with all subsequent edits, making sure that the integrity of the original duplicate is guaranteed. Ulrich ------------------------------------------------------------------------------ _______________________________________________ Darktable-users mailing list Darktable-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-users
