[un1versal]

Ive no idea how a skin controls this, I dont think confluence does and I have re-cached all my artwork with BICUBIC and it works.

[Hersan]

Just an update

With texturecache.py C i got it to work finally (I must have done something wrong before). All posters are looking much better now!

However the tumbernails (most recently added movies etc) in the center of the screen are compleatly unaffected by this (hence still look awful). This perhaps is by design?

Regards

[Martijn]

Just an update

With texturecache.py C i got it to work finally (I must have done something wrong before). All posters are looking much better now!

However the tumbernails (most recently added movies etc) in the center of the screen are compleatly unaffected by this (hence still look awful). This perhaps is by design?

Regards

This has not changed yet.
Devs are still thinking about which settings should be adjusted as well to have low impact

[Hersan]

Ok, thanks for the clarification.

Hoping one can set lanczos as scalingmethod for these aswell in the futue

Regards

[furii]

i finally had some free time to mess around with this again. the other week i did rebuild images with "texturecache.py C" on my openelec box and did not notice any increase in quality. that said, all results below are from today using the lastest nightly for osx kodi-20150925-f8a8413-master-x86_64 and confluence.

to start with i removed the kodi profile, started kodi, quit kodi, and added the following advancedsetting.xml:

Code:

<advancedsettings>
  <loglevel>1</loglevel>
  <imagescalingalgorithm>fast_bilinear</imagescalingalgorithm>
</advancedsettings>

i then took screenshots of three different views with three different poster sizes.

next i reset, quitting kodi, removing the profile, restarting kodi, quitting kodi, and adding the following advancedsetting.xml:

Code:

<advancedsettings>
  <loglevel>1</loglevel>
  <imagescalingalgorithm>lanczos</imagescalingalgorithm>
</advancedsettings>

again taking screenshots of the same three views.

lastly, i quit kodi, removed the profile, restarted kodi, and did not use an advancedsetting.xml. this should have resulted in kodi using bicubic resizing.

switching between images at 100% there was no noticeable difference in the artwork. to be sure i layered the images in pixelmator and set the blending to differences. as you can see, the only difference between the images is the time in the upper right hand corner.

watch gallery

being but a layman i can only begin to guess what is going on. based on the quality of the images and seeing what the webserver displays with different scaling methods it certainly seems like fast_bilinear is being used for whatever reason. that would seem to rule out the advancedsetting simply not working. since montellese, i believe, stated it's for artwork that is cached maybe skins aren't using the cache for some reason. although wither Hersan and uNiverse stating they've managed to get things working i think that would be a little surprising. since it seems to be broken on both osx and openelec maybe it's only working on certain platforms. i certainly would love to help try and track things down. obviously kodi is still usable but it would be really nice if this was working.

[Milhouse]

I've just tried this on a Revo 3700/ION2 running latest OpenELEC/Kodi16.

watch gallery

It's not apparent in the imgur gallery above (imgur is altering the quality of the artwork as it is uploaded - use this zip to compare the differences between Original 1000x1500 poster, and the cached Bicubic, Lanczos and Fast Bilinear artwork @ 480x720 with <imageres>=720)

After extracting the cached artwork from the Thumbnails folder, only once I've zoomed in several levels of zoom am I able to see fairly clear differences between Fast Bilinear and both Bicubic and Lanczos - mostly around the text at the bottom of each poster. The Bicubic and Lanczos algorithms are very similar to each other, with only very minor differences.

However when not zoomed in, all 3 of the algorithms appear to be very similar to the naked eye... perhaps you'll only see easily noticeable differences when caching much smaller images, where the loss of quality is likely to be more pronounced?

Anyway, with this OpenELEC system I'm confident that texturecache.py is working correctly and will re-cache artwork using whatever algorithm may or may not be defined in advancedsettings.xml.

[un1versal]

@Milhouse

I still think that a log line confirming the algorithm in use would be a good measure to assure people things are loaded and in use. Unfortunately all my attempts have failed since cant figure out where in code and the syntax of the log line o use.

[Hitcher]

since montellese, i believe, stated it's for artwork that is cached maybe skins aren't using the cache for some reason.

A different scaling algorithm is used when displaying the cached images in the GUI.

[furii]

since montellese, i believe, stated it's for artwork that is cached maybe skins aren't using the cache for some reason.

A different scaling algorithm is used when displaying the cached images in the GUI.

yeah, that's what i thought but Hersan stated that poster image quality was improved in confluence after rebuilding his cache. really don't understand the purpose of the advancedsetting if it's not going to affect the gui. and considering the thread topic is specifically about the gui i don't agree with this being marked as solved either.

@Milhouse, agreed that imgur is changing to jpg and adding compression but it's still clear that each image is using difference scaling. that's why i added the layered difference output to fully show there is no change between them. that said, pulling out of the cache doesn't really do anything since it's not being displayed in the gui that way.

[Milhouse]

@Milhouse, agreed that imgur is changing to jpg and adding compression but it's still clear that each image is using difference scaling. that's why i added the layered difference output to fully show there is no change between them. that said, pulling out of the cache doesn't really do anything since it's not being displayed in the gui that way.

I don't have any fancy image manipulation tools to show the image differences that's why I provided the originals.

Pulling the artwork out of the cache does at least prove that what is being written into the cache is honouring the correct scaling algorithm.

The GUI should be decoding the cached jpg exactly the same as any other image library would, yet the suggestion seems to be that it is displaying an alternative image. Perhaps an additional scaling step is taking place when displaying cached artwork, and this algorithm is poor quality which effectively "undoes" the good work of the better quality scaling algorithm when the artwork is first cached?

[furii]

Pulling the artwork out of the cache does at least prove that what is being written into the cache is honouring the correct scaling algorithm.

The GUI should be decoding the cached jpg exactly the same as any other image library would, yet the suggestion seems to be that it is displaying an alternative image. Perhaps an additional scaling step is taking place when displaying cached artwork, and this algorithm is poor quality which effectively "undoes" the good work of the better quality scaling algorithm when the artwork is first cached?

confirmed on my end that pulling straight from the cache does show the different scaling methods are being used when written there.

so the problem is definitely that the gui does not also use the same scaling method. obviously this makes sense when you think about it. the new scaling methods are used when writing to the cache but you're only writing one image size which the gui then resizes based on whatever the skin says to use. unfortunately the scaling method for the gui still seems to be fast_bilinear. it would be nice if whatever was specified in the as.xml was applied to both writing to the cache and the gui. as it stands now there isn't much use in saving higher quality artwork to the cache if it's not being displayed as such.

[axbmcuser]

Would love to see this change (GUI itself using better scaling method). Any news on this?


Especially on wall views with many items the posters would look so much better.


Is there a way to change the GUI-scaling method when compiling KODI 16 myself? Any hint where to look?

Thanks!

[Milhouse]

Just be aware that the higher quality scaling methods will typically be slower than fast_bilinear... not necessarily an issue for one or two items of artwork, but delays could become noticeable when displaying a wall of posters etc.

I do agree though that the use of a lower quality scaler by the GUI does make the higher quality scaler used by the cache largely pointless (it may still be of benefit to remote control apps, and web browsers, but not the GUI). Maybe a second as.xml setting to specify whether the GUI uses the same scaler as the cache...

[Martijn]

Forget about as.xml
GUI uses its own made up scaler which is not even fast bilinear. It should just be fixed to at least use a known scaler and go from there.

[axbmcuser]

Went through the source and already suspected that the GUI may use a custom scaler.

In you opinion, is it a complex task, targeting the change from the custom scaler to something familiar?