5 ms·

Cool work! I'm a fan of anything that makes things more efficient. Why not go a step further and have a server dynamically scale the image based on the size th

Cool work! I'm a fan of anything that makes things more efficient. Why not go a step further and have a server dynamically scale the image based on the size the image will be displayed at, so it's always displayed pixel for pixel and there's no waste? Anyone tried that?

eklitzke 9y ago
This works, but takes up a lot of CPU resources on the server. As always, it's a trade off.
matt4077 9y ago
THat's (almost) possible. You can obviously redirect requests to image-????x????.jpg to a script that resizes the source image to the requested size. To get the browser to request the correct size, you just have to add a bunch of them to the srcset attribute. I say "almost" because you're limited to giving specific sizes as options, and it's probably not a good idea to let that list grow to a thousand entries. However, the approach given in the linked project is actually much better, because - It works with only a single file, not one for every resolution. The latter makes CDNs useless with increasing number of possible resolutions - On-the-fly-resizing is slow - A streaming solution could just continue to read at the point it previously stopped if anything changes, such as the user clicking on a thumbnail to see the full image - It also allows to make the stopping decision at a later point. Currently, a browser may have only loaded the first few lines of a html page when it has to decide which of the available sizes for the image it wants to load. If it can wait a bit longer, it has better data about, for example, the network speed to the server and the layout of the page.
- dawnerd 9y ago
  Used to have a setup like this years ago but having a script that performs something heavy like image manipulation led to it being abused to ddos the server. You basically have to set predefined sizes but in that case you might as well render the images on upload and save all the versions.
  - eknkc 9y ago
    What we do is to add a signature to url. For example image.jpg?w=500&sig=<hmac of w=500> so the server can validate that the request url originated from us and we can add more image sizes by just generating new urls with correct signature. This solves the abuse issue while providing the same freedom for image sizes. Edit: Also we use aws lambda for image resizing so scaling is not an issue and generated images are cached on s3. Storage is cheap.

eklitzke 9y ago

This works, but takes up a lot of CPU resources on the server. As always, it's a trade off.

matt4077 9y ago

THat's (almost) possible. You can obviously redirect requests to image-????x????.jpg to a script that resizes the source image to the requested size. To get the browser to request the correct size, you just have to add a bunch of them to the srcset attribute. I say "almost" because you're limited to giving specific sizes as options, and it's probably not a good idea to let that list grow to a thousand entries. However, the approach given in the linked project is actually much better, because - It works with only a single file, not one for every resolution. The latter makes CDNs useless with increasing number of possible resolutions - On-the-fly-resizing is slow - A streaming solution could just continue to read at the point it previously stopped if anything changes, such as the user clicking on a thumbnail to see the full image - It also allows to make the stopping decision at a later point. Currently, a browser may have only loaded the first few lines of a html page when it has to decide which of the available sizes for the image it wants to load. If it can wait a bit longer, it has better data about, for example, the network speed to the server and the layout of the page.

dawnerd 9y ago
Used to have a setup like this years ago but having a script that performs something heavy like image manipulation led to it being abused to ddos the server. You basically have to set predefined sizes but in that case you might as well render the images on upload and save all the versions.
- eknkc 9y ago
  What we do is to add a signature to url. For example image.jpg?w=500&sig=<hmac of w=500> so the server can validate that the request url originated from us and we can add more image sizes by just generating new urls with correct signature. This solves the abuse issue while providing the same freedom for image sizes. Edit: Also we use aws lambda for image resizing so scaling is not an issue and generated images are cached on s3. Storage is cheap.