digiKam takes 2-3 seconds to display the embedded JPEG in a raw file. Settings > Configure digiKam > Album view > Thumbnail click action: Show embedded preview. "Embedded preview loads full-sized images" is not ticked. The same photos display much faster in Geeqie. This screencast demonstrates the difference in speed. I did wait for each preview to fully load in Geeqie before hitting the right arrow for loading the next one. https://minus.com/m8KXl7Q8D/2f
Geequie (last release in 2010?) seems to have some quick access code for certain raw formats. First question is which RAW files this applies to: format, size of preview? Can you provide a sample file?
Marcel sorry for not getting back to you sooner. I fixed my email notification settings now (hopefully). I tried only with Pentax K10D raw files. You can get them from here: http://rawtherapee.com/shared/test_images/ The last Geeqie update was in August 2012, version 1.1.
Hello, I beleive I am seeing the same problem. In this case, Digikam always is presenting a raw preview even though the "show embedded preview" option is selected. I have seen this behaviour in the last few releases of digikam (2.8, 3.0). I thought it was just me or how people were expecting digikam to work... Interestingly, I was working on another laptop using the same version of digikam (2.8) it it worked fine with the same file (canon 40D raw). The embedded JPG preview popped up fine (and labelled as such in the upper right hand corner). So I went back to my main system and checked and found I had some libraries installed from a previously tested PPA. It took awhile, but I reverted all libraries back to the packages from the ubuntu repository. This did not seem to help the main system which kept on presenting raw previews, regardless. I then went to each system and generated Help->Components information and copied to clipboard. I diff'd the two files and they were identical. Yet, different behaviour persists. Next, I closed miss-behaving digikam and moved the Pictures folder and .kde/share/config/digikamrc to a temporary folder. I restarted digikam and performed a clean startup. I copied the test file into the Pictures folder and ..... it still shows the "Half Size Raw Preview", not the embedded preview! So it does not appear to be a configuration or database issue. One major difference. The laptop is a 32 bit machine where the problem system is a 64-bit system. They both are running Kubuntu 12.10 with digikam 2.8. DrSlony, is your system a 64 bit or a 32 bit? Does anyone have an idea of what libraries I should double check? Thank-you and best regards, - Gerry
Created attachment 79528 [details] debug output of non working embedded preview. This is the output of the console with kdebugdialog settings enabled. This is with the enbedded preview option enabled in digikam on the 64 bit system
Just added attachment of console output on non-working digikam. When tested on the working system the only lines that appeared were: digikam(2553)/digikam (core) Digikam::DMetadata::getIccProfile: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam(2553)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation => 1 digikam(2553)/digikam (core) Digikam::DMetadata::getIccProfile: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam(2553)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation => 1 digikam(2553)/digikam (core) Digikam::DMetadata::getIccProfile: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam(2553)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation => 1
There are some heuristics to decide if the embedded jpeg can be used or the half-size preview need to be created. This was inspired by the multitude of RAW formats, some having very large and high quality preview, some low-quality. And by diverse user wishes. The most likely difference between your systems is screen size. For a larger screen, the minimum acceptable preview size will be larger, and this may just be crossing the limit. There's somewhere a wish on b.k.o. for the option "always use the embedded preview for RAWs"
Hello, Thank-you for the quick reply! I was looking at the code and saw the various size checking routines, and based on the debug messages and the condtionals in place guessed something similiar. I have downloaded the source package and was to instrument the code to confirm this was the problem. The troublesome system has dual monitors, would you expect that to contribute to this? I think the laptop actually has a higher resolution screen than just one of my monitors. So the problem might be because digikam thinks I have a really large screen. I'll dig around the B.K.O and see if I can find the "always use the embedded preview mode" wish... Thanks again!
Hello, I did some digging, and found that the hueristics were using the entire desktop when determining the size as a opposed to screen size. When running a dual headed system, this pretty much ensures that you will always be forced to use the half-sized preview with raw images that don't have quite large previews. In this case the raw image preview was 1536x1024 on 1680x1050 monitors. That seems a pretty good fit on one screen, but when dual headed, now it is 3360x1050. There is a hardlimit of 2560 (WQXGA), but you have to be within 80% of that--2048--otherwise, you are forced into a half size preview. I am pretty certain the intent was to use a single screen size and not the sum of all of the screen widths together. As it is, even through the embedded preview is almost the same size as the screen (within a 100 pixels) it always forcing to the half size raw preview. Attached is a patch to the current trunk which queries the default screen size instead of the entire desktop.
Created attachment 79580 [details] query screen size instead of desktop size for embedded preview decisions
Git commit c824672fbaeb7ef927633979b1d02eb9709750e1 by Marcel Wiesweg. Committed on 01/05/2013 at 14:49. Pushed by mwiesweg into branch 'master'. Apply patch by Gerry Patterson <thedeepvoice1@yahoo.co.uk> Use qBounds to be more concise. FIXED-IN: 3.2.0 M +4 -12 libs/widgets/graphicsview/dimgpreviewitem.cpp http://commits.kde.org/digikam/c824672fbaeb7ef927633979b1d02eb9709750e1
Git commit eb10fd009fc392a23ebd9dc409caab0da1d5843f by Veaceslav Munteanu, on behalf of Marcel Wiesweg. Committed on 01/05/2013 at 14:49. Pushed by munteanu into branch 'picassafacetag'. Apply patch by Gerry Patterson <thedeepvoice1@yahoo.co.uk> Use qBounds to be more concise. FIXED-IN: 3.2.0 M +4 -12 libs/widgets/graphicsview/dimgpreviewitem.cpp http://commits.kde.org/digikam/eb10fd009fc392a23ebd9dc409caab0da1d5843f
64-bit Gentoo
(In reply to comment #8) I have a 1920x1080 screen. Exiftool reports on my Pentax K10D raw PEF file: [MakerNotes] 0x0002 Preview Image Size : 640x480 [MakerNotes] 0x0039 Raw Image Size : 3872x2592 [Composite] - Image Size : 3936x2624 When I extract the embedded JPEG image I find that it has a resolution of 3872x2592 $ exiftool -b -JpgFromRaw amsterdam.pef > jpg.jpg $ identify jpg.jpg jpg.jpg JPEG 3872x2592 3872x2592+0+0 8-bit DirectClass 1.417MB 0.000u 0:00.000 In digiKam 3.1.0, when "Show embedded preview loads full-sized image" is disabled, previews load as fast as in Geeqie. I wish that button's name was not so vague and detached from reality.