Definitely a newbie question but I’ve just processed several raw files and saved them as jpegs. They, of course, have their xmp files. If send a jpeg as an attachment in an email do I also have to send the xmp file so it looks like the edited image? I’d prefer to just send the jpeg and not confused the recipient.
No, the XMP files contain the editing history and things like tags and star ratings. They are not needed to view the file.
I kind of thought so but thanks for confirming.
Followup question. That wouldn’t apply to a raw file would it? I mean if I emailed just the raw file without the xmp it would look horrible right?
No. It would not look “horrible”.
It would look/be in the state as before you started “developing” it.
Sounds like this would be a good source for you: darktable 4.2 user manual - darktable
plus a bunch of Boris Hajdukovic’s tutorials.
1 Like
This is not exactly true… I would say only if you view, ie reimport them into DT. I don’t use DT to view exported jpg files. I have them in their own file structure and use a different viewer… When they are exported no xmp file is created. I think if you check your xmp setting and if you wanted you could also set it to only create xmp after edit then I don’t think you would get xmp files for the exported jgs either when you import them unless you somehow modify them in DT… In fact for the most part you can load an exported jpg file as if it were an xmp file back to the original raw to apply the edits… in almost all cases the data needed is in the meta data of the jpg… so there is some nuance to how you manage and use xmp files… Many people use this setting as they dont’ want unnecessary xmp files unless they actually make an edit be it raw jpg tiff whatever…
1 Like
Yes, a bad choice of words. I’m viewing Boris’s videos, they’re very informative.
Early on, I came to a way of thinking about my digital images that really is just a perpetuation of the old film ways. That is, raw files are like negatives, JPEGs are like prints. To extend that a bit, raw files are the sum total of data captured at the scene, and JPEGs are renditions of that data for particular purposes. For instance, when I get home with one or more shooting sessions, I first batch-process my raws to “proof JPEGs” 800x600 renditions with standard processing. If I want a full-resolution version, I re-open the raw with the original proof processing, change to suit, and re-export. I don’t give anyone anything other than a JPEG rendered for their specific need/desire.
Also, I don’t propagate all that raw metadata to the renditions. In my renditions, I just include the basic exposure/author/copyright tags; I don’t think others want to know all that other stuff.
Note - I don’t use darktable, I use other software that saves the processing tool chain that made the JPEG in the JPEG metadata. No sidecar files, I don’t care for that mechanism. I think ART also will do this.
Great explanation. Many thanks.
If I could ask, what software do you use and what is ART?
Its a fork (or offshoot)of RawTherapee. Rather good!
https://bitbucket.org/agriggio/art/wiki/Home
1 Like
Yes, it sounds very nice. I think I might give it a try.
Thanks again!
1 Like
But it looks like a one-person project now, at least last commits have been done by a single dev. Sadly, I’m not sure this fork has any future.
1 Like
Yes, and I’m not fully versed in Linux enough to figure out how to install it.
Its been chugging along for several years now… Seems to be fine to me.
1 Like
darktable can embed XMP in exported files as well.
ART is a fork of RawTherapee.
I use software I wrote, uncreatively named ‘rawproc’. It stores the tool chain used to make the JPEG in the ImageDescription EXIF tag, mainly because I’m too lazy to figure out how XMP would do it.
Now, the key bit to how this just makes my day every time I do raw work is, when I drag a JPEG with a rawproc toolchain in it to the rawproc icon on my desktop, rawproc will go looking for that toolchain and if it finds it, ask me if I want to open the raw file instead and apply the tool chain. If I say yes, then rawproc does that, takes a couple of seconds (depends on the toolchain), and presents me with the raw processed to where the JPEG was rendered. From there, I can change the toolchain to suit, and save either over the old JPEG (with new toolchain), or save a different JPEG.
This really well-supports my highlight-weighted exposing. When make my batch proofs, shots in different lighting will be various degrees of what most folk think of as “underexposed”, owing to using my camera’s highlight-weighted metering (not proper ETTR, but the similar objective). What I’ll usually do is to open the first proof of such a sequence answering the above question ‘yes’, and then adjust the tone curve to lift the shadows to suit. I then save that proof with the new tone curve, then I delete all the subsequent proofs in that lighting and run a new batch job with the new processing. The batch version of rawproc knows to ignore already-existing JPEGs in that directory, and just re-generates the deleted proofs with the new tone curve.
Yeah, a bit of work, but that’s the price of highlight-weighted (ETTR or othewise) exposing, instead of lamenting lost highlight data one has to deal with the low end. But how rawproc is organized makes that burden palatable to me. Now, I didn’t set out specifically to facilitate that, it all just fell into place as I wrote the software. But it was an early decision to eschew sidecar files that made it all pretty straightforward; each rendition produced by rawproc, whether JPEG, TIFF, or PNG, contains the processing that was used to create it. That, and the distinction between raw files just being about scene measurements and JPEGs being renditions for specific purposes has made my imaging workflow pretty simple (well, to me, anyway… 
)
What Linux distro do you use?
The simplest way is:
- Click the Download button
- If you wish, move the file to a directory of your choice.
- Open a command prompt (terminal, console) in the directory where the downloaded file resides
- Issue the command indicated on the download page:
chmod +x ./ART.AppImage - Type
./ART.AppImageto run it.
Alternatively:
- Right-click the file in your file manager
- Set the executable flag
- Double-click the file to launch it.
Thanks, I ended up installing AppimageLauncher and then the ART appimage. The whole appimage thing seems to work well.
ART looks nice but I’ll have to play around with it some more.
Glad you got it to work. ART’s author, @agriggio, is also on this forum. The ART category is here: https://discuss.pixls.us/c/software/art/36
You’ll find a FAQ and tutorials.
If you haven’t given up on darktable, I encourage you to stick around. There are quite a few of darktable users here, me included.
Another project of interest is RawTherapee, which is the original project ART grew out of. It is also actively maintained.
Perhaps you could spend some time with all of them (and/or with others), and decide later. If you have a supported GPU, darktable will receive a huge speed boost. You don’t need top-end: my NVidia 1060 is much faster than my Ryzen 5 5600X CPU.
Yes, thanks, I’ll still use DT as I think It’s very powerful and probably the best of the bunch.
I re-processed those missing images I had mentioned in another thread and this time they didn’t go anywhere. I mean they’re where they should be so I guess I messed something up previously. Anyway it’s been a good learning experience. I’m also realising the folks here are very helpful.