Req Resize Images on the fly
#1
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://SCRAPPER_IMAGE_URL/


Thanks. I wouldn't be suprised it exists but I cannot find it!
Reply
#2
It's something we want but nobody has ever done it.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#3
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
Reply
#4
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.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#5
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.
Reply
#6
(2014-10-21, 20:35)Tolriq Wrote: 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.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#7
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.
Reply
#8
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.
If you have problems please read this before posting

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.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#9
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
Reply
#10
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.
Reply
#11
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 Smile
Reply
#12
(2014-10-24, 08:14)joethefox Wrote: 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.
If you have problems please read this before posting

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.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#13
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.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#14
I've made a PR for above changes, see PR5573.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#15
@Tolriq: If you're interested in testing this on a R-Pi, I've included PR5573 in my latest test build.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
 
Thread Rating:
  • 0 Vote(s) - 0 Average



Logout Mark Read Team Forum Stats Members Help
Resize Images on the fly00
This forum uses Lukasz Tkacz MyBB addons.