Of course, you're free to do with your RAWs whatever you want. I, personally, would leave Darktable when it messed with my RAW images.
Sherwood Botsford (2020-Jan-29, excerpt): > Camera makers understand that their cameras have to work with other > editing tools. Wrong. They have proven repeatedly that they don't care shit about free software. The open source community is way not strong enough to participate in the power play between companies like Nikon and Adobe. It is, sadly, economically irrelevant in the Photo industry. There may even be financial incentives to not have open source software understand the RAWs, because then users are forced to buy commercial software, whose producers pay money to camera manufacturers to get access to image format specs. > Yes: There needs to be extensive checking with each firmware version > to check that things don't break. How do you imagine this works, who's doing that? How many firmware versions are out there? What about metadata that is not understood by the open source community, how does it relate to the data you want to edit? You seem to assume that the undisclosed metadata has no relation to what you want to edit, but on what grounds? We don't know. Whoom do you expect to give you any guarantee (or just a promise) that such editing will not break any existing or future images? Whoom will you blame when this happens? > you need to decide how paranoid to be: Simple: If there's data of which you do not understand exactly how to reproduce it consistently, do not mess with it. > I have been bitten by the "I can't find the original" of this image > several times, and I only have about 40,000 images. Well, then don't be so messy. You have file names (with a counter rollover after 10k shots), date and time, and other metadata that propagates from the RAW to the exported image. Sherwood Botsford (2020-Jan-30, excerpt): > I have had incidents with Aperture where it had to rebuild a library Make backups of the library. Backups of metadata are very small compared to backups of images. If the RAW images never change, infrequent backups of the images and frequent backups of the (volatile, separately stored) sidecars will save you a lot of space and time. If the RAWs change, you have to back them up every time. > I responded to the orientation question because it's one of the > cases that is very simple. No, it's not, because... > If I can do so safely, ...you can not. That's the whole point. Nobody understands RAW images good enough to give you a guarantee to not break the image. > at a minimum I want a unique ID in the master image Best bet is to have the ID derived from, and stored *outside* the image. Maybe rename the image to its SHA1, or store it in the sidecar, along the lines Guillermo Rozas suggested. > At best I want all critical metadata -- the stuff that takes hours > to put in -- keywords, caption, description to reside in the image, It is a bad idea to mess with the RAWs. Because we are not in control of the format. > and in the database, and in the sidecar files, and in every derived > image. And this is just another very bad idea: You create redundancy. There is good (backups) and bad redundancy, and the difference is subtle (cf. data provenance), but your suggestion clearly introduces synchronisation problems. -- Dr. Stefan Klinger -- Informatiker, Mathematiker o/X https://stefan-klinger.de /\/ I prefer receiving plain text messages, not exceeding 32kB. \ ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
