https://bugs.kde.org/show_bug.cgi?id=454206
--- Comment #9 from Martin Kyral <sine.nom...@centrum.cz> --- 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. -- You are receiving this mail because: You are watching all bug changes.
