Make it possible to extract and use the JPEG embedded in RAW files

[frivoal]

Is your feature request related to a problem? Please describe.
Most raw files included an embedded JPEG. In some cameras, it is even a full-resolution JPEG. Currently, in darktable, there's no way to make use of it, except in the very limited sense when they're used to initialize the thumbnail/preview cache.

Most of the time, I shoot RAW because I want to control what the result looks like. But sometimes, the in-camera settings actually result in something that is very much to my taste. And sometimes, some images are challenging and getting something I like from the RAW file can be difficult. And sometimes, both happen at the same time, and I'd be pretty happy to just use the JPEG (maybe make some minimal tweaks), and move on.

Also, occasionally, it could be nice to use the (embeded) JPEG as the source in the color mapping, and the RAW as the target, but you can only do that if you have access to the JPEG.

Describe the solution you'd like

I'd like to optionally be able to swap out the normal RAW pipleline with an extract-JPEG-from-RAW stage, followed by the normal JPEG pipeline.

I'm thinking it would be a combination of three things:

1. a processing module, to be used at the very first stage of the processing pipeline, which would take a RAW file as input, and provide the embeded JPEG as output. Maybe it can have a parameter to select which JPEG we want if there are several, but likely going with the highest resolution one is enough.
2. a new "module order", alongside with "v5.0 for RAW input" and "v5.0 for JPEG/non-RAW input", called something like "v5.0 for JPEG extracted from RAW input". This is because the module suggested in step one would need to be at the start of the pipleline instead of the stack of non-optional modules actually needed for normal raw development. This new module order would be identical to the one for JPEG, except that it would have the "JPEG extract" module as the first thing. This would be manualy selectable from the module order dropdown for any raw file that has at least one embeded JPEG.
3. a new button in the duplicate manager, similar to "duplicate" and "original", called "extract JPEG" or something similar, available on raw files with at least one embeded JPEG.

Alternatives
Maybe I'm wrong that this would need a alternative module order. Maybe it can simply be a module, turned off my default, that sits at the very start of the RAW pipeline, and if turned on, it would turn off/bypass the other raw modules (pretty much: everything up to and including demosaic). Whichever makes the most sense architecturally.

A simple alternative is to use the camera's RAW+JPEG mode, and have it save both as separate files. However:

• When there's a full resolution (or high enough resolution) JPEG in the RAW file, that's wasteful of disk/card space
• If that's just for occasional use, it's easy to forget to set that mode
• I'd rather manage the resulting rendering as a duplicate, rather than as a grouped image. That's not very different, but the small difference isn't too helpful. These are two views of the same photo. Treating them as two different files, even grouped, isn't terrible, but it's not helpful either.

Also, I can do manually what I am suggesting that darktable would do here, invoke exiftool -b -JpgFromRaw input_file.CR2 > output_image.jpg manually, and import both files. However, the workflow would be simpler if that could be done without relying on external tools. Also, though this is a minor point, just like the RAW+JPEG camera setting, this results in two (grouped) files, not one file with one or more duplicate, and that's not ideal.

[wpferguson]

So IIUC this is what you want in generic terms:

• A way to extract the embedded JPG from a RAW while in darkroom
• A way to switch between the JPG and RAW, in darkroom, like duplicate manager

I'd rather manage the resulting rendering as a duplicate, rather than as a grouped image. That's not very different

Actually it's VERY different. One is an entry in the database referring to the original image (duplicate) and one is a separate physical image that has to be handled as an image.

a new "module order", alongside with "v5.0 for RAW input" and "v5.0 for JPEG/non-RAW input"

Module orders are for processing modules in the pixelpipe. Extracting a thumbnail or creating a duplicate are utility functions and don't belong in the pixelpipe or a pixelpipe order.

Extracting the JPG is a utility function that requires no processing from the pixelpipe.

---

Questions:

What if the image doesn't have an embedded full resolution JPG or no embedded JPG at all? Or what if the largest embedded JPG is only mipmap size 3 (Canon R7 for sure, maybe other Canon R series)?

[frivoal]

So IIUC this is what you want in generic terms:

• A way to extract the embedded JPG from a RAW while in darkroom
• A way to switch between the JPG and RAW, in darkroom, like duplicate manager

Yes. I don't mind also having some way in the lighttable to create one too, just like you can create a duplicate from the lighttable as well.

Also, I don't expect an actual separate JPEG file to be stored on disk as a result. The RAW file plus an XMP file with the right settings should be all we need to represent this.

Actually it's VERY different. One is an entry in the database referring to the original image (duplicate) and one is a separate physical image that has to be handled as an image.

Right. And it's that difference (despite superficial similarities in the lighttable UI) which make me prefer having it handled as some sort of duplicate with a different pipeline, rather than a separate file merely grouped.

What if the image doesn't have an embedded full resolution JPG or no embedded JPG at all? Or what if the largest embedded JPG is only mipmap size 3 (Canon R7 for sure, maybe other Canon R series)?

If there's no JPEG at all, the UI that lets user create one of those should be grayed out or otherwise deactivated.

If there is a JPEG, but it's of lower resolution, I'd still offer the option. Maybe we want a cutoff at some point when the image gets tiny, but then again, I don't think darktable has a general minimum resolution for images in general, so I am not sure we need one here. If the image you get is too small to be useful, then the user can see that, and not do it.

Module orders are for processing modules in the pixelpipe. Extracting a thumbnail or creating a duplicate are utility functions and don't belong in the pixelpipe or a pixelpipe order.

While module order may be the wrong way to go about it, I was thinking that we wouldn't extract and save to disk, but rather than it would sit in the pipeline, starting from the RAW file, and having this "extract" module replace the normal first modules that are normally applied to RAWs (RAW white/black point and demosaic, plus a few optional ones).

Maybe that doesn't mesh with how the internals work (sorry, not familiar), and the extract stage has to somehow be before the pipeline, and after that we just apply the regular JPEG modules. But as I mentioned above, my ideal solution doesn't result in any JPEG being extracted on disk and managed as a totally separate file, and would remain an interpretation/derivation of the RAW, albeit with a pretty unusual and rigid first step.