Support RAW+JPEG imports using JPEG for mipmap cache

[binhn2016]

This resolves issue #19470. When a user import a RAW+JPEG pair with the same file name, the JPEG will be used to build the mipmap cache for the RAW file

[TurboGit]

I'm not sure to understand, but isn't this already what is done when option "use raw file instead of embedded JPEG from size" is set to never?

Also when the RAW is modified we do want it to be used for the mipmap cache. Right? Is that what is done here?

We need quite more description about the semantic introduced here but note that I'm not convinced about this because it seems to overlap a current feature.

[quovadit]

I'm not sure to understand, but isn't this already what is done when option "use raw file instead of embedded JPEG from size" is set to never?

no, at the moment it does not use the embedded jpg for fullscreen, that's why I opened the issue.
My described solution was exactly to always use the embedded version, but wpferguson pointed out, that the resolution might not always be high enough, that's why he came up with the solution to copy the imported jpg.

[binhn2016]

This behavior only applies when importing the RAW+JPEG pair and can be controlled by toggling 'cache/import_raw_jpeg_optimization'

[jenshannoschwalm]

In short this means, you use the jpeg in case of a raw&jpg pair and the raw has no embedded hires jpg?

[binhn2016]

yes, but the code does not check for an embedded high-resolution JPEG. It always assumes the paired JPEG is the highest quality

[TurboGit]

Well you'll need some vote from other devs because to me adding such a complexity for a corner case usage sounds like a bad idea especially since some camera are starting to add large embedded jpegs on RAW.

[wpferguson]

@jenshannoschwalm is there anything special about the mipmap jpgs? If I dropped a camera JPG file in as a mipmap would it work?

@TurboGit if it will work, then this would be fairly trivial to implement as a lua-script.

[quovadit]

Well you'll need some vote from other devs because to me adding such a complexity for a corner case usage sounds like a bad idea especially since some camera are starting to add large embedded jpegs on RAW.

I don't see, why this is a corner-case usage. Browsing through imported raw images in fullscreen to rate them before editing is currently unusable in my opinion, because it calculates the processed preview everytime I jump to the next image.

Maybe it's necessary to check whether the embedded jpg is large enough, and then use the embedded or the paired jpg?

[jenshannoschwalm]

is there anything special about the mipmap jpgs? If I dropped a camera JPG file in as a mipmap would it work?

Nothing special, they get scaled. And are kept in a special location. Anyway for me this a cornercase ...

[wpferguson]

Browsing through imported raw images in fullscreen

fullscreen images are not the same as full resolution images which is what the separate JPG from camera would provide. Fullscreen images still need to be downscaled from the full resolution when you request them. For instance on a 4K screen fullscreen images are mipmap 6. Full resolution are mipmap 8

EDIT: But downscaling from mipmap 8 to mipmap 6 is much faster than reading the raw and generating mipmap 6.

[TurboGit]

I don't see, why this is a corner-case usage.

Because you need RAW+JPEG and amongst all photographers I met only one is using RAW+JPEG. Also with the crawler the preview are calculated in advance... So it should not make a difference in speed. Maybe you have set the crawler setting with too low mipmap resolution. And again all this code just for this temporary is not good to me, as soon you edit the image this won't be used. So really do we need the extra complexity, to me the answer is no.

[quovadit]

I don't see, why this is a corner-case usage.

Because you need RAW+JPEG and amongst all photographers I met only one is using RAW+JPEG. Also with the crawler the preview are calculated in advance... So it should not make a difference in speed. Maybe you have set the crawler setting with too low mipmap resolution. And again all this code just for this temporary is not good to me, as soon you edit the image this won't be used. So really do we need the extra complexity, to me the answer is no

As described in issue #19470 I just import a RAW file (no +jpg), open the raw in fullscreen in lighttable, and it waits for some seconds and switches to the processed raw instead of the embedded jpg.

I don't know, why I am the only one having this issue, maybe it's my camera (Canon R3 with CR3 files), but I definitely don't see this as a cornercase if I want to see the fullscreen image of an imported raw for culling.

[TurboGit]

I don't know, why I am the only one having this issue

Don't know either, maybe a bad setting or the computer is slow. But as you say yourself it seems to be an issue for you and we don't have more reports on this. So a corner case :) Maybe we need to fix the root issue instead of adding some unneeded complexity.

[quovadit]

It could be an issue with CR3 from canon.
I tested 10 different raw-files from different brands, and had the same issue with cr3 from canon r7 and r5

The embedded jpgs are definetely large enough, exiftool -JpgFromRaw extracts them without problems.

So it's no issue for the majority, but not exclusively for me.

So is there any chance, this fix could be integrated? Maybe using another mechanism when to do the copying? (only for cr3 / toggle in darktablerc / ...)

[wpferguson]

I built a script to do it. I just need to test on windows.

EDIT:

It could be an issue with CR3 from canon.

I have an R7. I think Canon only includes embedded JPGs for the sizes they use in camera. The largest embedded JPG in my R7 raw files is mipmap size 3. Full screen on a 4k monitor is mipmap 6, 2k - 5, HD - 4, so the only way to get a full screen or higher resolution image is to generate it from the raw. I have a script, responsive cache, that runs after import generating the cache sizes I need (3, 6), because I don't want to shoot RAW+JPEG.

Testing with the script copying the JPG to mipmap 8 and then doing full screen culling at mipmap 6 was smooth with no waits.

[TurboGit]

I have a script, responsive cache, that runs after import generating the cache sizes I need (3, 6), because I don't want to shoot RAW+JPEG.

Just curious, how is this different from enabling the Darktable crawler? As soon as I import pictures the crawler starts and create the mipmaps (max size in preference) on my side.

[wpferguson]

Just curious, how is this different from enabling the Darktable crawler?

Your camera has a full resolution embedded JPG. The crawler can pull those at a rate of 100 images/sec (roughly). Once the full resolution JPG is extracted the rest of the cache can be built quickly by down scaling.

In my Canon R7 the largest embedded JPG is mipmap size 3. So if I try and generate a full screen preview (mipmap 6) the image has to be processed and the JPG generated from the raw. My system can do 3 images/sec.

So I wrote a script for me, responsive cache, the runs after import and builds the thumbtable cache (mipmap 3, so just an extract) and it runs at 100 images/sec. So I can start scrolling through the lighttable without waiting for thumbnails to be built. While that's going on I start extracting the full screen previews (mipmap 6) for culling. That runs at 3 images/sec because the raw has to be processed and converted to a JPG.

A normal filmroll for me is ~1000 images, so I spend 5 minutes scrolling through lighttable and then I start culling.

---

If I shoot a RAW+JPEG pair I could:

• copy the JPEG to the mipmap 8 folder and rename it to the image id of the raw (if the raw was image id 234 then I would copy the JPEG to the 8 folder and name it 234.jpg)
• If the crawler ran after this then it would generate the cache very quickly
• even without the crawler, having the full resolution JPEG available will allow building the needed cache by down scaling.
• the preview image will have all the makers secret sauce applied versus looking at a unprocessed raw export

---

I think this is somewhat of a corner case but it seems to affect all(most?) Canon mirrorless cameras

[wpferguson]

Here's the script

use_paired_jpg_as_mipmap.zip

Unzip it and drop it in your lua-scripts, then start it. It doesn't discard the paired JPEG by default, but you can configure it in the Lua options

[wpferguson]

I tested my script last night after shooting 2 games with 700+ images per game. I shot RAW+JPEG.

I imported each game. The script ran when import finished and took maybe 5 seconds to copy the JPEG's to mipmap size 10 (because of the mipmap size changes in master). After that I triggered my cache building script and it took 25 seconds to generate all the cache I need. Done the way I was currently doing it (processing the raw to generate larger sizes) it would have taken 4+ minutes. The bonus to this is that I get the full resolution image in the cache if I need to use it.

The script needs one final fix to make sure it puts the full resolution JPEG in the correct location (mipmap 8 or mipmap 10) based on darktable version number.

The script solution becomes more viable once #19899 is completed because it can be included with darktable and the user simply has to turn it on. The script by default keeps the JPEGs, but it can be configured to delete them after copying them to cache.