Raw images opening very slowly on fedora default image viewing application and other image viewers. It should not be hardware related thing, because with an emulated image viewers designed for windows OS raw files opening in an instant (with native image viewers it takes about six sconds to open an image).
Are there no photographers or artists that use Fedora?
This is a forum, not paid support.
Waiting only a few hours then bumping your own post is bad form and wins few friends.
One thing you might do to improve your chances of assistance would be to include all the important data.
What version of fedora are you using?
Is it updated?
What app is being slow to load the image?
What is a “raw image”? What format is it in? png? jpg? gif? or?
The more relevant information you may provide the more likely someone may be able to assist.
From the Start here category the Welcome to Ask Fedora! Please read me first! topic shows this about asking for assistance.
You should try to make things easier for others that try to help you.
Check to see if the information you are looking for is documented on in the Fedora documentation 28.
quick-docs 28 provide lots of short one page step by step instructions on how to do many things.
Search this forum before you post: someone may have asked the question before, or experienced the issue before you.
Always mention the version of the Fedora OS you are using.
Try to clearly document what you were doing, step-by-step if you can.
Provide as much relevant information about your system
Commands that tell you about your system, its hardware, its packages and so on are documented here 34.
Don’t worry if you can not gather more information, though. Other users will ask you what what they need, and you will learn in the process too!
I am using Fedora 39 KDE and Silverblue updated. On both computers all image viewing applications (gThumb, Gwenview, PhotoQt, Image Viewer and other) all raw image files opening very slowly. I have an old canon camera that makes .CR2 files, but I downloaded from internet sony, fujifilm, nikon, new canon raw files (.ARW, .RAF, .NEF, .cr3) and it is the same - slow or not showing at all. On windows or in bottles emulated windows viewing programs those raw files oppening in an instant - it cannot be hardware related. Also Silverblue not even showing thumbnails.
There you could download samples: Sample galleries: Digital Photography Review
The text below (source linux dot com), shows the main dilemma and also displays why on Windows it works faster. I do remember that while formatting the memory card from my cameras, I had to do this in the cam it selves. Conclusion might be that the cam is using a own Filesystem where had to be made compatible with additional software etc.
As in many other things the RAW format is, when it came up, closed source and every company cooked his own soup. As in the “old days” drivers where made with Windows and probably for Apple devices only, nobody cared about.
File under fire
The RAW formats themselves are specific to digital camera manufacturers. Canon’s current format uses the extension .cr2, a successor to the preceding generation’s .crw. Nikon uses .nef, Minolta .mrw, Fuji .raf, Pentax .pef, Olympus .orf, Hasselblad .3fr. Although most are based internally on a variation of the hyper-extensible TIFF, all are proprietary and subject to change with each new camera model, and most are officially undocumented.
There are two RAW formats not produced by camera manufacturers. Foveon’s .x3f was created by chip maker Foveon for its special image sensors, found in cameras manufactured by Sigma and Polaroid. In 2004, software giant Adobe announced it was launching a new RAW format called .dng that would serve as an umbrella format for all of the others. The company produced a free DNG Converter application, but as of today DNG has not taken over. Many see the DNG move as a blatant attempt to take over the RAW format market by a jealous software house not currently a player — and for most digital SLR owners, since DNG is not the format their cameras actually capture in, it is nothing more than another (unnecessary) intermediate format.
Of course there are photographers under us. It is just so, if you really want to get deeper you will be better served on a Digital forum where has Linux users who reported the issues you have. I do believe they are Linux Distribution independent.
Fedora might be a bit exceptional because it is not delivering all the codecs and/or software for the thumbnails by default. The reason are the license the software is published.
As mentioned above, try to take in to account the time-line/Story of the RAW file format and as @computersavvy already mentioned use some patience while we do not offer payed support. The responds and responds time is a bit different and not always a guarantee.
While searching in Duckduckgo I also found a git repository where eventually gives you some assistance with your problem.
To process Raw images I use Rawtherapy or Darktable, I cannot even understand what Fincer/linux-cameratools is for nor how to install it - raw image temperature, ISO value (I am guessing that Rawtherapy also do not crop sensor information - images are a little bigger than edited in Photoshop)? So from what you have told it seems that Fedora will never be able to implement raw image thumbnails because of a licensing and image viewers will never be as fast as on windows or mac.
So most probably it is best on Linux to use emulated windows or mac image viewing apps?
My favorite app is “Fast Stone” image viewer. I am running it from bottles so its launch is little slower than directly installed in wine, but it should be safer I guess. I am struggling a bit to make it a default image viewing app on Silverblue.
Thank you for reply’s.
No, I wrote it not comes preinstalled (by default) … you have to tweak it till it works for you if it is available for Linux.
It looks like you really have to search every piece together … try this one:
It was for F25, if you find it as a maintained package it probably still works:
ufraw works as a tool to edit RAW images and it opens reasonably fast.
I use a Gnome Workstation not Silverblue.
raw-thumbnailer is no longer maintained after Fedora 38. Additionally, in Fedora Silverblue, the
/usr/ directory is designed to be read-only.
For better RAW image support, I would consider a switch to KDE. As you said in another post, KDE’s file manager Dolphin generally supports most RAW image thumbnails, and I think DigiKam can handle of many RAW images effectively.
Edit: I should also mention that both Dolphin and DigiKam are available through Flatpak installations.
Yes, usr/ read-only and
thumbnailers folder in it
Actually “Fast stone image viewer” is faster because of a viewing mode - it has three: embedded preview image(fastest)(default), half size(medium) and full size(slowest). If it is set to full size it is actually slower than any other Linux viewer and when I compare images 1:1 in full size it is clear that all Linux image viewers always loading images in full size mode.
I am using image viewers to delete photos that are badly exposed or composed and for that quick viewing mode is needed. Problem is that most Linux viewers do not have that “embedded preview image” mode. Or they do?
I found one it is called “nomacs”. It have an option in raw loader settings to enable “Always load JPG if embeded” (it suports many RAW formats except new canon cr3).
Maybe there are more image viewers that have this option?
I contacted a PhotoQT app developer regarding slow raw files and some bugs in the program and that is what he replied:
"- I pushed some changes to the code that fix the hiding of the status information and the handling of the Escape key for shortcuts.
- PhotoQt uses LibRaw for decoding and displaying RAW images, and LibRaw can indeed load embedded thumbnails. There was a logical mistake I made in the code that meant that PhotoQt always loading the full image. This is now fixed and loading thumbnails for RAW images is now (on my machine) between 5 and 10 times faster, though the exact speedup will vary from machine to machine.
All of these changes will ship with v4.2. I don’t have a date for that release yet, but it will likely be in January, rather sooner than later."
That is cool!