Thread Rating:
  • 0 Vote(s) - 0 Average
Strange resizing behaviour with <thumbsize> tag set in advancedsettings.xml
I've set the following in advancedsettings.xml:


to force XBMC to cache cover images (thumbnails) at a higher resolution because I wasn't happy with the display quality of the cover images it was importing from my folders.

The setting worked and the quality HAS improved.

But, I've been looking in the cache folders at the actual .tbn files it is creating and I opened them up in GIMP to look at the actual image size of the tbn files it's caching.

I'm a bit puzzled by what I'm seeing.

I have the thumbsize set to 1500 pixels which according to the wiki means that the image can be a maximum size of 1500x1500 pixels.

The source image is 1000x1500 (the standard cover image size on

And yet, the tbn file produced by XBMC has dimensions of: 836 x 1253


Why hasn't it kept that image at it's native size as it is on disk when it converted it to a tbn file?

If <thumbsize> is set to 1500 there should be no reason to downsize the image as I understand it.

The thing is, the resultant image IS much bigger than the default image size, so the setting is clearly working, just not quite as I expected.

I'm interested to understand what math / logic is being applied when resizing and caching.
There's an upper limit of 1024. Note that this almost always exceeds the size of the image displayed in the UI, so it's a waste of time, RAM and space.

The dimension set in advancedsettings is the geometric mean of the image size (reason is we support all sorts of different aspect ratios - compare banners with posters for example - a single setting for both doesn't really make much sense). This typically gives a better result than specifying a maximal dimension, as 512 would give quite small banner images (smaller than is shown in some skins) yet would give large album covers (larger than what is shown in most skins) - probably about right for posters in most skins though.

Note that the thumbnailing system (in particular how they're stored) is getting an overhaul at the moment, so this may well be changed in future.

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Thanks for the feedback Jonathan.

That makes perfect sense to me and seems like a reasonable limit.

Worth nothing, however is the fact that in your Wiki at :

It says the following:

Size of the square in pixels that XBMC will use to cache thumbnail images. If the thumb is smaller than this size it will be cached as-is. If it is larger it will be scaled so that the number of pixels is less than a square of this value. Default is 512, which refers to 512x512 = 262144 pixels in total. The thumbnail will be cached at using the same aspect ratio as the original image, using up to 262144 pixels.

That is clearly saying that the value given is effectively the maximum value either vertically or horizontally (whichever is larger) and the total pixels allowed for the image is that value multiplied by itself.

It doesn't mention the concept of geometric mean or mention anything about an enforced maximum value.

I think it's probably a good idea to update that Wiki entry with a more detailed explanation of that setting and the kind of information that you have given me in this post to avoid confusion in the future.


Strange resizing behaviour with <thumbsize> tag set in advancedsettings.xml00