[Kempniu]

Greetings,

Searching the forums I have come across several reports about picture browsing being slow in XBMC. I have the same problem using an Asrock A330ION mobo equipped with an Intel Atom CPU.

Opening a picture with a resolution of 4000x3000 pixels (that's what my digital camera produces) directly from hard drive takes around 3 seconds. Preloading the next image helps, yes, but browsing through a set of 100 photos is a pain in the neck in these circumstances. I've skimmed through XBMC code and I saw that rather than using some external library for picture scaling, it uses plain hardcore math to do the conversion and I supposed that is why the whole operation is so sluggish on a weak CPU. Question is, is there any way to make picture browsing quicker on a slower CPU, like maybe using a lower-quality algorithm for scaling? I really do not wish to scale 100+ GB of photos to a lower resolution.

To rule out other reasons for my problems, please note that lower resolution images (say, 2048x1536) are displayed at a very acceptable speed (almost immediately after switching). And while I'm viewing a high resolution set of photos, my CPU is almost constantly hogged at 100%.

Can anyone share their experiences in this matter?

[jmarshall]

It doesn't use any "plain hardcore math" for picture scaling. It uses the built in libjpeg scale-by-factor-of-2 stuff. The bicubic scaling there is essentially a noop, right?

[davilla]

install libjpeg-turbo, it's a drop in replacement for libjpeg and runs 2-3 times faster.

[Kempniu]

Thank you for your input.

jmarshall, I was basing my guess on the contents of SlideShowPicture.cpp - looks like XBMC is too large of a project for me to comprehend I couldn't find any references to libjpeg in the code I was looking into, so that's where my intuitive guess came from.

davilla, thanks for the suggestion, I'll try libjpeg-turbo later today and I'll report back with the results.

[Kempniu]

As promised, here are my findings: I have installed libjpeg-turbo and if we're talking about my subjective feelings, there is a visible speed improvement. A 12 megapixel image now loads in about 1,5-2 seconds - that's about twice as fast as before. Though I'm not ecstatic about it, I do understand we're talking about a low-end CPU here.

Another question though: as preloading the next image is a great feature, are there any chances to implement preloading more than one image at the same time? Right now if you start a slide show and wait even an hour, only the next image will be preloaded. Would it be possible to preload more images so that pausing on a single image for a longer period of time will enable the user to browse more swiftly through the following images?

[mrfatboy]

Sorry for the noob question. Can somebody please explain how to install the libjpeg-turbo libraries? I'm on Windows 7 x64.

thanks

[codemokey]

That library only applies to linux based operating systems. I don't think there is an equivalent for Windows.

[codemokey]

... are there any chances to implement preloading more than one image at the same time? ...

I couldn't agree more! I'm using an ATOM CPU too and have the same problem. I bought this machine specifically to run XBMC since it has an ION graphics set, but it is absolutely useless for looking at photos. The CPU maxes out, the machine becomes unresponsive.

I love XBMC for videos and music, but it is completely useless to me for looking at photos. I always have to quit XBMC and use Ubuntu directly. I've been using the built in jpeg viewer "Eye of Gnome 2.32.0" and it is very quick and responsive for looking at photos even on this slow CPU.

[codemokey]

install libjpeg-turbo, it's a drop in replacement for libjpeg and runs 2-3 times faster.

I tried that library which had some small improvement. I found these instructions for installing it on Ubuntu or other Debian based systems:

source:
http://cloud.ubuntu.com/2010/11/show-off...-on-cloud/

(here's the steps copied from that link. I also replaced version 1.0.1 for 1.1.1 which seemed to be the current version at the time I checked)

# wget 'http://sourceforge.net/projects/libjpeg-turbo/files/1.0.1/libjpeg-turbo_1.0.1_i386.deb/download' -O libjpeg-turbo_1.0.1_i386.deb
# dpkg -i libjpeg-turbo_1.0.1_i386.deb
Selecting previously deselected package libjpeg-turbo.
(Reading database ... 25967 files and directories currently installed.)
Unpacking libjpeg-turbo (from libjpeg-turbo_1.0.1_i386.deb) ...
Setting up libjpeg-turbo (1.0.1-20100909) ...

# ls -l /usr/lib/libjpeg.so.62
lrwxrwxrwx 1 root root 17 2010-11-12 12:35 /usr/lib/libjpeg.so.62 -> libjpeg.so.62.0.0
# rm -rf /usr/lib/libjpeg.so.62
# ln -s /opt/libjpeg-turbo/lib/libjpeg.so.62.0.0 /usr/lib/libjpeg.so.62

[Kempniu]

If we don't hear from the devs soon in this thread, I might try requesting that feature (preloading more than one image during slide show) via trac later, but for now one more issue has drawn my attention. According to the docs, if there is no thumbnail cached for a given image, XBMC will extract its EXIF thumbnail if it's available (and it's available for all photos I take with my camera). In my case, when I generate thumbnails for a new folder, it takes around a second to produce a single thumbnail and looking at the logs, I just see:

Code:

07:37:20 T:2860497776 M:2830073856   DEBUG: Caching image '(cut)' as '2/27546686.jpg' thumb size
07:37:20 T:2860497776 M:2830073856    INFO: Caching image from: (cut) to special://masterprofile/Thumbnails/2/27546686.jpg with width 512 and height 512
07:37:21 T:2860497776 M:2830106624   DEBUG: Caching image '(cut)' as '4/41eebe31.jpg' thumb size
07:37:21 T:2860497776 M:2830106624    INFO: Caching image from: (cut) to special://masterprofile/Thumbnails/4/41eebe31.jpg with width 512 and height 512
07:37:22 T:2860497776 M:2830245888   DEBUG: Caching image '(cut)' as '7/740ba883.jpg' thumb size
07:37:22 T:2860497776 M:2830245888    INFO: Caching image from: (cut) to special://masterprofile/Thumbnails/7/740ba883.jpg with width 512 and height 512

Doesn't look like EXIF thumbnails are being used at all, which doesn't surprise me as any command line tool like exif extracts dozens of EXIF thumbnails in less than a second on my hardware. Also, between the "Caching image from" entries I've found this one:

Code:

07:37:15 T:3018155760 M:2829869056   DEBUG: SECTION:UnloadDelayed(DLL: special://xbmcbin/system/libexif-i486-linux.so)
07:37:15 T:3018155760 M:2829869056   DEBUG: Unloading: libexif-i486-linux.so

Which kind of backs my observations Anyone experiencing a similar issue?

[jmarshall]

EXIF thumbnails are not high enough resolution to warrant bothering.

[Kempniu]

They are low resolution, but if I'm browsing through 500 photos, I'd rather skim through ugly, blocky images for 15 seconds than wait for eye-candy thumbnails for 10 minutes Any chance of giving the user a possibility to bypass the resolution requirement for EXIF thumbnails? I thought about <thumbsize> in advancedsettings.xml, but I don't know whether XBMC interprets this setting as a minimum thumbnail size, at least it's not the way it's described in the docs.