[swebs]

Well let's limit the possibilities to any image between 1x1 and 1920x1080.

Calculating the number of possible images is simple enough. It's just 1920*1080, or 2073600 images.

Now what's the average size of each image? Well the average of each dimension is half of the full size, so the average area should be 1/4th to of a 1920x1080 image, or 518400 pixels per image.

So in total, we need to save 1074954240000 pixels. Now how many bytes does each pixel take to store? I really don't know. You can save them as 8bit RGB PNG images and assume each pixel will use 24 bytes. You'd add some for headers, and remove some to account for compression, but let's ignore that for now. Maybe someone else can chime in. But for now we need to store 25798901760000 bytes, or about 23TB.

Not impossible, but sounds needlessly expensive.

[k2xl]

Maybe not needlessly expensive? Seems to be around 600$ per month (rounding up) on AWS to store there. So maybe 8k a year depending on traffic?

Plus like another commenter mentioned you can also just store multiples of 10 and you are at 80$ per month.

Plus, how much Dev time would be saved from this simpler approach? Multiply average hourly rate and you may have saved money.

[lonelappde]

You can easily cut that by a factor of 100 simply by serving only multiples of 10pixels for sizes over 300px.

And cut by another factor of 10 for jpg compression

[emilfihlman]

It's also possible to have the same base image that you cut a portion out of, so you wouldn't need to store an original image for each possibility, just cache results of cropping as needed.

[cabaalis]

I'll bet that most image requests will be within certain parameters. 2^x by 2^y. So you could probably pre-cache most real-world image sizes, and leave dynamic generation for 1-offs.

[davinic]

AND you could try to figure out how to do that beforehand, but some LRU-type cache solves the problem without any prior knowledge of what those sizes are.

[anamexis]

Well, that's what they're doing.