Bug 454206

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