[millerf]

Hi there,


I am building a web app and I would like to be able to resize the images (movie thumbnails mainly).

I notice I get this king of URLs for the images:

http://XBMC_IP/image/image://SCRAPPER_IMAGE_URL/

Is there, or is it possible to be able to resize them 'on-the-fly', as the sizes of theses images are quite huge and make my browser (on iOS) slow down...

Somehting like

http://XBMC_IP/image/HEIGHT/WIDTH/image:...IMAGE_URL/


Thanks. I wouldn't be suprised it exists but I cannot find it!

[Montellese]

It's something we want but nobody has ever done it.

[millerf]

Is there any reason behind that?

I just developped a small plug in on wy webserver to do it and cache it, but I don't like having to pass through another service/computer to do so

[Montellese]

Because in most cases you eill request the resized image multiple times and resizing it on request every single time is very ineficient (especially on low-power hardware). But we also can't cache every resized image in xbmc because that would take up a lot of space.

Therefore we need to find a middle way where we define fixed widths or heights that are available and can be kept in the cache. But there was no real consensus on thst.

[Tolriq]

For me it's client responsibility to manage cache of re-sized images.

You just need to provide correct HTTP cache headers and 304 answers based on change of original image cache.

Just talking from my side but dealing with Android devices with 6 different possible DPI so 6 different size for the same image in the same screen depending on phone, means if size are limited on server side they won't be very useful.

[Montellese]

For me it's client responsibility to manage cache of re-sized images.

You just need to provide correct HTTP cache headers and 304 answers based on change of original image cache.

Just talking from my side but dealing with Android devices with 6 different possible DPI so 6 different size for the same image in the same screen depending on phone, means if size are limited on server side they won't be very useful.

Well they are already limited now. You only get the image in the original resolution. The idea was to provide a few additional sizes like 256px width and 512px width (with adjusted heights). That way you don't get exactly the size you want but especially in case of e.g. 256px width you can still save a lot of bandwidth.

But yes it comes down to who is responsible for caching. The problem with HTTP caching headers is that our webserver doesn't really have that functionality i.e. we don't keep track of what has been requested by who and if that file has changed in the meantime.

[Tolriq]

IMO, for fixed size on XBMC side but not ending with hardcoded values on clients that could change over time, solution would be to have some kind of contract like I ask for an image size and XBMC sends back an image that is known to be the smallest possible but yet equals or bigger than the one asked.

For caching, it's never the job of webserver to keep track of anything. You just need correct headers with default values about cache and should use for example etag to compare and return 304 or not depending on the case.

For a best result it would be cool to store the cache value of source server about an image when downloaded from internet but is really not mandatory to have something that works.

[topfs2]

We could implement a kind of round robin harddrive cache for scaled images. However I agree that in general we should be able to trust the client to cache them. Web browsers are very good at it for example, I guess we just need to set the proper headers for it.

[da-anda]

we also need a garbage collector for cached images and textures. Having such a gc I don't think disc size would be much of an issue - it's not like one is using 20 different remote client apps wich all require different sizes

[joethefox]

IMHO in 2014 resizing and caching an image on the client side seems a reasonable thing to do without any extra efforts on the xbmc server side.

[Tolriq]

Even in 2014, 100% of 3G / 4G provides does set bandwidth caps and limitations.

So as I said 100% agree caching should be done on client and should not be done on XBMC, but re-sizing have interest for lots of user cases. Download full HD fanarts to display them on a 3.5'' phone is not efficient

[topfs2]

IMHO in 2014 resizing and caching an image on the client side seems a reasonable thing to do without any extra efforts on the xbmc server side.

Not all clients are able to do this simply, for example web interfaces.

If we would provide support for serverside resizing its up to the client to decide if it wants to use it, it would not be forced upon them. If the client is fast and would rather handle it (because its a responsive app for example) then it should/could.

[Montellese]

Our webserver already provides the Last-Modified and Expires HTTP header fields in responses and it handles the If-Modified-Since HTTP header field in request so partial caching support is already there. I've taken a closer look at HTTP caching and added some additional functionality in https://github.com/Montellese/xbmc/compa...er_caching:

• Providing Cache-Control: max-age=<x> public in responses
  
• Handling of Cache-Control: no-cache and/or the old and deprecated Pragma: no-cache in requests
  
• Handling of If-Unmodified-Since in requests
  

These changes should improve caching provided by clients and webbrowsers and should give better control over local caching.

[Montellese]

I've made a PR for above changes, see PR5573.

[Milhouse]

@Tolriq: If you're interested in testing this on a R-Pi, I've included PR5573 in my latest test build.