Hello,
is there a possibility in DT to natively export the preview image contained in the RAW? Or in other words, what is the best way to proceed if I only want to develop/edit selected images and still export the rest as a jpg that more or less matches the preview image contained in the raw?
Why am I asking this: I shoot exclusively in RAW and don’t want/need to develop all my images; many fit like the preview image displayed. I realize it is only a relatively small jpg, but for certain purposes that would be enough for me.
What have I tried:
I generated a style for myself that doesn’t include any changes. But even this generated jpg looks very different from the preview image displayed in the light table.
Unfortunately, my attempt to generate a style that matches my camera and use it also failed.
Simply exporting also leads to results that I can’t use because the basic changes of the scene-related editing are applied and the photos look duller and less colorful.
One idea would be to shoot raw + jpg. But how can there be a process that prevents the data volume from exploding even faster than it already is? That’s why I still prefer to keep only the RAW and delete the exported jpg after use in prints, photo books or slideshows. I believe that this way I am future-proof and can possibly get even more out of my images with new DT versions.
And then just overwrite the previews with the output from darktable.
You could even do that automatically or rather not, depends on your level of cautiousness.
Hey, @Claes: (vielmehr: “Grüß Gott”, wie wir Franken zu dieser Uhrzeit sagen würden)
@Claes ,@grubernd : Thanks, that’s what I’ve been lookin’ for. I see I need to spend more time with the great exiftool
I will now check for which situations the exported jpg is sufficient and if, as hoped, it is at least sufficient for prints and photo books, then I will have the jpgs read out into another directory, use them accordingly from there and delete them after use. Great, I can get through a holiday like this in Scotland with around 3500 pictures much quicker.
Note that there might be more than one size of the preview/thumbnail image embedded in the raw file depending on the format/vendor/model, so you can also try w/ -b -preview:all to extract and inspect them all.
I have a lua script + small c++ code based on exiv2 to do that from darktable (see attached code).
The lua script add a function accessible through a shortcut that operates on selected images.
The cpp code extracts the best jpg and then the lua code creates a darktable group so that the jpg and raw files are linked together.
Highly dependant on your camera.
For example Nikon has had fullsize previews in NEF for at least 15 years.
PS (edit): A camera without fullsize embedded JPGs should never be used for anything where focus matters since that is what you can examine on the camera display. This becomes more crucial the higher the pixel count of a camera.
Disk space is cheap these days. If you store 50 MB per image you could save 20,000 images per TB. That would cost you ~$50. If you use a standard HDD this would be much less. Compare that to the cost of analogue film photography .
So, I would advise to shoot RAW and JPEG and live with the 30% or extra space used.
Thanks! By studying the exiftool parameters I saw exactly that. But my RAW file only gives me thumbnail and preview.
I also came across jExifToolGui and have installed it and exported from there. There, too, I only get There I also get thumbnail and preview.
Yes, that’s right; I was already thinking about that. The effort involved in the process on the PC has just been too much for me so far.
If the other way proves unsuccessful, then I will probably have to proceed in this way.
@foto NowI think, I need tutoring.
The export of the preview from my ORF file has a size of 32002400 pixels and that with my raw file of only 52403912 pixels.
I have integrated such an export into the photo book program I use and made it as large as I wanted in the A4 (11.7 * 8.3") format I use. There were no limitations - at least in the preview or quality check. OK, of course I can only really judge it once the book has actually been produced. I’m really inclined to just give it a try.
Am I making a mistake?
You will be fine.
3200x2400 pixels is easy enough for A4.
Print quality calculations are easier in metric mode:
A4 is 30cm … with 100ppcm you need 3000 pixels.
100ppcm amounts to 254ppi which is more than enough. [1]
Depending on the printing method that the book-store uses, usually half the resolution (50ppcm) is still okay for anything that is not super detailed. This would require only 1500 pixels for the long side of A4. That is not even a 2mp file.
[1] Side note: the old 300ppi rule comes from hardcoded printing machines with rasters that would completely screw up your image with heavy moireé when anything else than 300ppi came into that machine. Most of the time the original scan material was way below that because after rasterization no one could see the difference. It is similar to todays inkjet printers: no one sends a true 2400ppi image into the printer.
To print my own books, I use MagCloud which is now owned by Blurb.
Whoever you are going to use for printing your book has ‘specs’. Follow them to the letter.
What I do not understand is why use the preview for your book AND use Darktable?
If you are resizing your image, I strongly recommend that you do somne further sharpening OUTSIDE of Darktable after the resize.
When printing, the sharpening should be between a 1/3rd to 1/2 more than for the screen.
Me, I use ImageMagick for the resize + sharpening and I try different sharpening strength to see which one works for this particular image. Here’s what I use in Linux. It should also work with a Mac and could be changed slightly for Windows:
@grubernd: Thank you. Now I can understand why Fotobook-SW compresses the images before sending them. They simply don’t need the full size for printing.
@foto: “What I do not understand is why use the preview for your book AND use Darktable?”
I use the exported thumbnails for simple things (snapshots, family celebrations, en passant photos…). And the quick and easy export is enough for that.
I manage my RAW photos in Darktable and need it for the clean processing of the photos (blue hour, astro, long exposures, macros, …) that make it into our “more artistic” photo books that we display and look at again and again in the apartment as well as for the photos needed in slideshows. For this I need a very good raw developer and I think DT is exactly that. Comprehensible?
Thanks for the tip about sharpening. I’ll have a look at that. Your process sounds good.
@ to all: The discussion has brought me a step further in my entry into Linux, DT & Co. Thank you!
.