[un1versal]

Thx Milhouse, suspected as much lets see if I dont break this trying bicubic.

[un1versal]

The only observation about the new feature is:

There's seems to be no logging indicating that the algorithm was loaded OK or is in use (for as.xml)

Seems like it would be both beneficial and ideal just in case a user picks some method not compatible with their platform. But OK this was just added so room for improvement.

[furii]

i'm trying to figure out if i'm doing something incorrectly, if i'm misunderstanding what should be improved with this, or if things are not currently working correctly. of the three the first would be preferred

i'm currently running a build fritsch put together here. it's based on git and currently reports version 16.0-ALPHA3 Git:6feada8. it was rebased on current kodi git yesterday so this new scaling should be implemented.

my advancedsettings

below are three screenshots i took with various settings. specifically look at the Archer thumbnail as i ran ./texturecache.py C tvshows "Archer" to rebuild those thumbnails.

before advanced setting

bicubic_spline

lanczos


as you can see there is almost no difference between the three, and certainly no improvement. hopefully i'm just making a stupid mistake somewhere.

[Milhouse]

below are three screenshots i took with various settings. specifically look at the Archer thumbnail as i ran ./texturecache.py C tvshows "Archer" to rebuild those thumbnails.

I'd suggest restarting Kodi after updating the texture cache to ensure there is no additional caching performed by Kodi which may result in an old image being displayed even though the artwork has been updated in the texture cache.

as you can see there is almost no difference between the three, and certainly no improvement. hopefully i'm just making a stupid mistake somewhere.

Try using the old "fast_bilinear" algorithm to see how it used to look (it should be noticeably worse than bicubic).

The new default "bicubic" algorithm is an improvement on "fast_bilinear", but perhaps there's simply not much difference between "bicubic", "bicubic_spline" and "lanczos"? What kind of difference are you expecting?

[furii]

fast_bilinear vs. lanczos vs. osx kodi nightly lanczos vs. image resized in pixelmator

caveat: i'm not sure what resize algorithm pixelmator uses.

for each image i changed the scaling method in as.xml, rebooted, ran texturecache.py, rebooted, took the screenshot. image is cropped and saved to png so there are no compression artifacts in play.

if you open the first two images in new tabs and switch back and forth there is no difference so it seems like my advancedsetting is either not being recognized or not working for some reason. the pixelmator resized image is what i was hoping the new setting would accomplish. the title text is unreadable in the kodi resized pictures but about as legible as you can expect considering the size of the image in the pixelmator version.

perhaps it is a bug in fritsch's branch. i don't believe there is an oe nightly build of jarvis which i could try. i can try running it on osx but then i'm looking at at completely different os and hardware setup.

edit: was able to quickly test on osx with the latest nightly and scaling is the same.

[Milhouse]

i don't believe there is an oe nightly build of jarvis which i could try. i can try running it on osx but then i'm looking at at completely different os and hardware setup.

OpenELEC Jarvis x86_64 builds.

[furii]

i don't believe there is an oe nightly build of jarvis which i could try. i can try running it on osx but then i'm looking at at completely different os and hardware setup.

OpenELEC Jarvis x86_64 builds.

doh, you beat my edit

[Milhouse]

Be aware that your setting in as.xml only applies to software-based (ie. CPU) image scaling - some platforms, eg. RPi, employ hardware accelerated (ie. GPU) scaling and you have no influence over the algorithm used.

[furii]

Be aware that your setting in as.xml only applies to software-based (ie. CPU) image scaling - some platforms, eg. RPi, employ hardware accelerated (ie. GPU) scaling and you have no influence over the algorithm used.

i did see that but i'm not on an rpi which is also supposed to have better scaling. oe testing was done on a chromebox while osx testing was done on a hackintosh. afaik neither should be using hardware scaling. as universal stated previously it would be nice if there was some actual confirmation in the log as to what was being used.

[Hitcher]

Is the scaling method used for everything or just the caching of images?

[Montellese]

The scaling is only applied to images that we download from scrapers or read from local metadata and then resize before we store them in Kodi's thumbnail/texture cache. The easiest way to check the differences of the different scaling algorithms is to use the webserver. For that you need to get the artwork path of an image (e.g. from the database or through JSON-RPC) and then open

Code:

http://<ip>:<port>/image/<url encoded image://<artwork path>>?width=<x>&scaling_algorithm=<scaling algorithm>

That way you can try all the different scaling algorithms without having to change advanced settings etc and you can easily save the result. This does NOT save the result in Kodi's texture cache. It simply shows the result in your browser.

TBH I've never tested the scaling algorithms on such small images. I only use views with large posters so posters usually have a width of 600-700px. There you can see a huge difference between fast bilinear and bicubic or lanczos.

[furii]

checking with the webserver was much easier than how i had been going about it, thanks
it also produced results that were much more desirable:

fast_bilinear - lanczos - bicubic - bicubic_spline

at that size there is hardly any difference. and in regards to testing against such a small size i did it because it's when images get downscaled the most that they look the worst. something like this (ignore the compression artifacts imgur decided to introduce) where the poster width is ~400 things are pretty ok.

so now that i know it's capable of producing better images the question is why isn't it?

it looks like something is wrong with xbmclogs so i've just pasted my as.xml:

Code:

<advancedsettings>
  <loglevel>1</loglevel>
  <videoextensions>.m4v</videoextensions>
  <gui>
      <algorithmdirtyregions>3</algorithmdirtyregions>
      <nofliptimeout>0</nofliptimeout>
      <visualizedirtyregions>false</visualizedirtyregions>
  </gui>
  <imageres>1080</imageres>
  <fanartres>1080</fanartres>
  <imagescalingalgorithm>lanczos</imagescalingalgorithm>
</advancedsettings>

it looks ok to me but maybe i've got something set incorrectly.

since this commit set bicubic as the default scaler i hopped on my osx machine and removed my entire kodi directory, added that one show, and the poster is still clearly scaling at fast_bilinear.

[Hersan]

Hi

Running latest Kodi nightly on OSX (latest whatever version)

Just wanted to shime in that I too have been wondering why setting "lanczos" in as.xml dosn't have any effect. Not even the "new" default scaler bicubric seems to be working because newly scanned posters look just as jagged and awful as before (with default fast_bilinear).

Apart from a log entry that simply show what my as.xml contains, I can't find anything that indicate that the setting have acutally kicked in. Not that the default scaler is switched to bicubic either.

It is truly a long awaited feature and I thank you so much for implementing it, however it dosn't seem to work as expected yet on at least my machine.

I'll post a Debug Log when I get home tonight.

regards

[un1versal]

I already had suggested that some logging be added to confirm the as setting has been loaded. I even tried adding it myself with my awful non existent C++ skills, devs reactions were something to the effect of: "No why should it!"

Even despite quite other (not all) poignant as.xml settings offering some logging feedback it seems that this is not important enough for a lousy log entry.

[furii]

i had a quick PM with hitcher about this setting and it's his understanding that it only affects the images kodi stores when scraping artwork. however displaying them in the skin does not use the new scaling method. if that's actually the case then i don't really understand the point of having the setting at all.