Ask HN: Why have browsers not provided a client solution for image scaling yet?
12 comments
I think one reason is that image resizing algorithms are nontrivial. An image uploader sounds simple enough until you start supporting many different scaling algorithms [1] across a bunch of formats. Browsers are already big and complex enough IMO. This could be easily / best handled by a library instead.
Another point is that holding onto the unmodified images server-side (and merely serving a cached, resized, optimized version on the fly) can be beneficial for future use cases.
Check out, e.g., Thumbor [2] if you're curious to see more of the complexities involved. I have self-hosted it for a company before, and it worked well.
[1]: https://en.wikipedia.org/wiki/Image_scaling
[2]: https://github.com/thumbor/thumbor
Another point is that holding onto the unmodified images server-side (and merely serving a cached, resized, optimized version on the fly) can be beneficial for future use cases.
Check out, e.g., Thumbor [2] if you're curious to see more of the complexities involved. I have self-hosted it for a company before, and it worked well.
[1]: https://en.wikipedia.org/wiki/Image_scaling
[2]: https://github.com/thumbor/thumbor
In most cases where users are uploading images, you probably want to get the biggest possible version you can get for more future flexibility. It's always possible to make a larger image smaller, but making a small image look good bigger in the future isn't possible as that extra detail would be lost.
Not always, Look at Instagram, there's a really big reason the web page support is not the same as the mobile client. It much easier to deal with these types of issues natively than in some web agent. There is a huge cost to uploading all those images into memory and scaling server side vs the savings letting the clients do the work. Also having access to the source is not exclusive to the client doing the work vs the server.
I'm not a Facebook/Instagram user so I don't know how they work, but is it true that they don't ask users to upload the biggest possible images/videos they have? Kind of shocked as I thought they'd always want to siphon up as much information as they possibly can.
[deleted]
I thought Javascript and canvas worked fine?
https://hacks.mozilla.org/2011/01/how-to-develop-a-html5-ima...
https://hacks.mozilla.org/2011/01/how-to-develop-a-html5-ima...
I have done this before with wasm and other libs too, but the issues is that you still have to load the image into the dom in somecases this can become an issue for large images. Given the size of images on phones now a days and then trying to run something like this on the mobile browser and you will quickly find out way this is not optimal. I would rather the browser did more heavy lifting via simpler JS apis. AS3 still has better graphical api compared to JS today. Canvas just does not cut it.
Because it's done server side so that the minimal size can be sent to the client whilst also aiming to get maximum quality. It means you don't always have to send the largest highest image to every user, you can just send the most efficient/appropriate image. i.e. If you wanted a thumbnail of a massive image and it was done client side then you'd have to send that massive image even if it wasn't needed.
[deleted]
Because you should be processing the images on the server side anyways. I guess it would be nice to cut down on file transfer size, but at the end of the day you need size limits enforced on the server. I recommend pulling in an image processing library on the server side and reformatting it before saving it, in order to eliminate a class of issues with invalid images.
"do i look like i know what a jpeg is i just want a picture of a god dang hot dog" -- My Chrome browser
So that's the original end of that meme!
Given the frequency of this of this super common wanted behavior in websites, why is it that we have GPS tracking and webcam stuff like webrtc but we still can't scale a common jpg? Google, Mozilla? Anyone?
https://www.youtube.com/watch?v=EvKTOHVGNbg