Feat: Dynamic Image Resizing

[nelsonic]

At present we have single size image resizing: 7. Resizing/compressing files
This is a very good starting point, 👍
but it sets and artificial constraint
that ends up looking "meh" on most devices.

Story

As a person using multiple devices to view the App - that features image content -
I want images to conform to the device/screen size
So that they always look their best.

As noted in #91 our friend has created https://github.com/jupiter/rust-image-worker
which appears to be well-documented and tested and runs on Cloudflare with CDN caching. 🏎️
While it currently does not have support for certain formats jupiter/rust-image-worker#3
But the underlying library does support GIF and Webp: https://docs.rs/image/latest/image/enum.ImageFormat.html#variant.Gif

Todo

• Follow the deployment instructions in the repo: https://github.com/jupiter/rust-image-worker#how-to-use
  • Create a new file to document our setup/deployment in _even _more detail: dynamic-resizing.md
• Bonus Level: Create Pull Request extending the image support: Project Maintained? jupiter/rust-image-worker#3 (comment)

[ndrean]

@nelsonic I am curious. ,You must probably have read this article. Since (obviously) you are using a server to upload image, what is the reason you did not consider to run your own Task to compress the image before saving to S3? You would save a bucket and a lambda. Something obvious I am missing?

[nelsonic]

@ndrean hadn't seen that fly.io blog post published Mar 13, 2023; thanks for sharing.

It's quite superficial, not really a "tutorial", more of a "you can do this thing"
but you have figure out the precise details on your own ... 🙃
That's exactly the kind of post that mega frustrates me.

To answer your question:
we want to maintain the original image so that people can view as much detail as possible.
We will save money when we switch to using B2 #98
I don't have anything against optimising the images in a Task in Elixir.
But I would prefer to minimise the Elixir bottleneck and use an existing Rust project to the just-in-time optimisation.
From an experience perspective the Elixir approach where you perform the immediate resizing could be better in terms of response time. ⏳
We could test it.
For now the S3 buckets + Lambda function works "OK".
Have you implemented image compression/resizing in Elixir? how fast was it?

Ultimately using B2 + Cloudflare which is "free" for their CDN would save us money (over S3 + Lambda)

[ndrean]

@nelsonic, Yes superficial indeed, but it gives ideas.

But aren't you serving the client back with a compressed image?
https://user-images.githubusercontent.com/17494745/242736344-bd61d716-8a4e-445f-a643-8f5d13a00510.png

that's why I imagined it was an extra step (and I always fear AWS costs....).

I forked the repo but did not run it yet but I plan to as I never did this server-side nor loaded files yet with Phoenix. But I have no intention so far to send something to S3, too much bills with AWS.

I maybe totally wrong but I thought a simple URL.createObjectURL for the preview was enough, although I have no idea if Liveview accepts this.

I will also try the https://hexdocs.pm/image/Image.html and explore

[nelsonic]

Yeah, the current AWS bill is currently Zero because it's all in the "Free Tier".
Which is why the priority on #98 is priority-2
Returning the compressed image URL is a stop-gap and will be phased out in due course
instead the device will request the size of image that best fits the viewport #91
therefore prospectively resizing becomes wasteful.
If the device uploading the image is 600px wide there's no need to have images 200px or 2000px wide.
Then when subsequent devices attempt to view the image, if they can request dimensions that best suit their viewport without a significant latency penalty, that's super desirable.

Very curious to see your exploration of the https://github.com/elixir-image/image library. 👌
I didn't find the docs to be particularly beginner-friendly when I tried to read them a few months ago ... 🤷‍♂️

I'm especially not a huge fan of risk of crashing the whole BEAM with one malformed image:
https://hexdocs.pm/image/readme.html#security-considerations

If I can offload image processing/resizing to a totally separate Rust micro-app I'm going to chose that every time. 🚀
But if I needed to do Image recognition in Elixir then the image library looks interesting. 💭