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.