I have the same issue... loading folders with few hundred RAW photos, or even a single (1) RAW photo takes ages to load. Loading just one RAW image takes about 7 seconds to load, and while it's loading, the Gwenview process has CPU usage of 300%. On the other hand, something like Geeqie loads RAW images (even hundreds of images) basically INSTANTLY. Gwenview is just unusable for RAW image viewing.

Even digiKam is significantly faster than Gwenview, but not as fast as Geeqie.

The RAW photos in question are Canon's .CR2

Loading JPEG images is fine.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.5-rc5
Graphics Platform: Wayland
Graphics Drivers: mesa-git (23.3.0_devel.176075.8c62b3938a8.d41d8cd-1)
Processors: AMD Ryzen 9 4900HS
Memory:  24GB of RAM
Graphics Processor: Integrated: Vega 8
Manufacturer: ASUS (Zephyrus G15 GA502IV)

Well, I just guess but with a grain of knowledge as I implemented the original RAW support in gwenview back in 2013:

 * the original KDCRaw-based implementation used the preview image bundled in the raw file itself. That's fast as it's only reading the already prepared preview data and treating them as jpeg (you can get the preview using dcraw -e file.raw).
 * it seems to me that alternative implementation using Qt Raw plugin and it is being preferred
 * from quick peek at the code I assume, that with Qt Raw plugin the trick with using the preview that's aready present is not used (I am not sure if Qt Raw plugin can do that)
 * demosaicing takes time

I consider this to be a major regression.

By regression I mean the feature is virtually unusable.

Another downturn is that while with KDCraw you get the image straight from the camera, with Qt Raw plugin the image looks different, rather dull and underexposed as the demosaicing algorithm and colour science is proprietary to the camera manufacturer and thus hard to replicate. While with full raw converter the user has wide palette of tools and settings to do the colour science and processing to their liking, the number of adjustments provided by gwenview is ZERO and providing them is far out of scope of it.

Probably the solution is to insert a configuration in Gwenview to force the use of KDcraw even when the RAW plugin is present. The code to use KDcraw is still present in Gwenview as it is used if, for example, the RAW plugin is not found.
This way everyone does what they want.

Or, completely restore the old code: in this way KDcraw is always used by ignoring the RAW plugin at all.

The config option seems perfectly fine to me. Let the user decide that's best for them.

The problem is, that KDCraw fucntionality is apparently broken (maybe by kimageformats 5.99) for quite a while. So, the KDCraw code is still present but broken. I tried myself with gwenview patched to prefer KDCraw.

I am looking into the code trying to understand what happens with the data.

(In reply to Martin Kyral from comment #6)
> The config option seems perfectly fine to me. Let the user decide that's
> best for them.
> 
> The problem is, that KDCraw fucntionality is apparently broken (maybe by
> kimageformats 5.99) for quite a while. So, the KDCraw code is still present
> but broken. I tried myself with gwenview patched to prefer KDCraw.
> 
> I am looking into the code trying to understand what happens with the data.

What happened in kimageformats 5.99? Qt Raw pluging support was implemented. That broke kdcraw pipeline in gwenview, which  has been 'fixed' by forcing gwenview to use the Qt RAw plugin as well, which works with the small caveat that it is by orders of magnitude slower, than what was before, rendering gwenview virtually unsable in some use cases (such as crawling through a folder with large number of raw files, which is very common situation everytime one comes home from a shoot). I suppose, kimageformats Qt Raw plugin code shall be reviewed and fixed so it doesn't break code in gwenview that does not utilize it.

Just to have a glimpse: I was extracting the embedded hi-res jpeg image using dcraw -e (the method kdcraw uses as well) from 150 raws from 16mpx Olympus. It took under 500ms. Compare it to the Qt Raw plugin which takes several seconds per image.

After some time I looked at the issue again and got some success: the breakage by the kimageformats update was apparently caused by kimageformats somehow affecting the formatHint value, when I hardcoded the format value to "jpeg" for RAW images processed by the KDCraw pipeline, it works. However, I also needed to backport the patch forcing QtRaw plugin in order to get into the KDCRaw pipeline in the first place. With my rudimentary patch, the RAW preview looks like it used to look: it is fast (loading an image in a split second) and it shows the images as get by the camera. Once again: for most manufacturers, the colour science is proprietary and it gets some tweaking if you want to demosaic the raw data and get acceptable colours (getting the colours as if processed by the camera/manufacturer's software is virtually impossible). 

With this progress, I'd like to ask if it's acceptable/manageable to have the preferred RAW processing pipeline (QtRaw or KDCRaw) configurable by the user. Now, IIUC the switch to KDCRaw pipeline would require recompiling QtImage with QtRAw disabled.

Build of gwenview patched to prefer KDCRaw (Fedora 40 only):

https://copr.fedorainfracloud.org/coprs/mkyral/gwenview/

Created attachment 171952 [details]
Patch to use KDCraw over QtRaw

Patch to use KDCraw over QtRaw

Thumbnailing was fixed by this commit:

https://invent.kde.org/graphics/gwenview/-/commit/0bcb8b3a9f408475645b569efd3cb007fd0e0e52

Browsing folders with images is now usable again. However, viewing of an image still uses QtRaw which is a) slow b) generates ugly previews.

(In reply to Martin Kyral from comment #12)
> Browsing folders with images is now usable again. However, viewing of an
> image still uses QtRaw which is a) slow b) generates ugly previews.

I was rereading this bug, and maybe (I have to check if it's possible) I could add the "jpg" subformat to the QtRaw plugin. If set, it returns the preview if it exists otherwise it generates the image from the raw (with the fastest mode).

This way there would be two subformats: raw (default) and jpg.
I have to check if it's possible for readers. The Qt doc is contradictory: the list of subformats seems made for writers, while setting/reading the subformat for reader and writer.

For plugin disabling... I was recently considering standardizing cmake scripts and making all plugins disableable (currently only some can be disabled). This would not be a solution for GwenView: it would depend on the distro's choices. Unfortunately Qt does not provide a way to disable a plugin at runtime. So we would have to do something dirty (e.g. via environment variable and for consistency it should be implemented for each plugin).

Anyway, I'll take a look at it in the next few days and let you know.

(In reply to Mirco Miranda from comment #13)

> This way there would be two subformats: raw (default) and jpg.

Unfortunately it's not possible to set subtype in QImageReader.

(In reply to Mirco Miranda from comment #13)

> This way there would be two subformats: raw (default) and jpg.
> I have to check if it's possible for readers. The Qt doc is contradictory:
> the list of subformats seems made for writers, while setting/reading the
> subformat for reader and writer.

since the below format is not the way, I used quality 0 for the preview: https://invent.kde.org/frameworks/kimageformats/-/merge_requests/299

*** Bug 497741 has been marked as a duplicate of this bug. ***

Thanks for working on this problem. Just to clarify: almost all raw formats contain actually two jpg previews: the 160x120 thumbnail (which is not usable even as a thumbnail now) and larger jpg preview which is either full-res (Nikon, Canon... ) or with reduced size but still enough for casual viewing (it is what you see at the back display of the camera when reviewing images). You need to get the correct (larger) one from the raw file.

(In reply to Martin Kyral from comment #17)
> Thanks for working on this problem. Just to clarify: almost all raw formats
> contain actually two jpg previews: the 160x120 thumbnail (which is not
> usable even as a thumbnail now) and larger jpg preview which is either
> full-res (Nikon, Canon... ) or with reduced size but still enough for casual
> viewing (it is what you see at the back display of the camera when reviewing
> images). You need to get the correct (larger) one from the raw file.

Good to know. I changed the MR: when compiled with libRAW 0.21+, the plugin automatically selects the largest preview in the file.

(In reply to Martin Kyral from comment #17)
> Thanks for working on this problem. Just to clarify: almost all raw formats
> contain actually two jpg previews: the 160x120 thumbnail (which is not
> usable even as a thumbnail now) and larger jpg preview which is either
> full-res (Nikon, Canon... ) or with reduced size but still enough for casual
> viewing (it is what you see at the back display of the camera when reviewing
> images). You need to get the correct (larger) one from the raw file.

We merged MR !299 (https://invent.kde.org/frameworks/kimageformats/-/merge_requests/299). It will be included in KF 6.11. 
You can set the quality parameter to 0 to load the preview.

You can do it with something like this:

QImageReader ir("fileraw.rawsuffix"); // e.g. "image.cr3"
ir.setDecideFormatFromContent(true); // needed
if (ir.format() == QByteArray("raw")) {
   ir.setQuality(0); // read preview
}
QImage img;
ir.read(&img);

Note that the quality parameter is normally dedicated to writing. Here it was used as a hack to set parameters to libRAW. To know all the possibilities see the plugin header: https://invent.kde.org/frameworks/kimageformats/-/blob/master/src/imageformats/raw_p.h