You are viewing a single comment's thread from:

RE: Did Steemit Inc. just destroy all our images?

in #steemit6 years ago

I doubt that's something they do to really reduce their costs, but rather to save bandwidth usage for their users.
If you look at the Steemit condenser repository on GitHub, and look around a bit, you'll find the pull request #3111
The Pull Request descriptions says the following:

Caps blog post image size and should finish the work to dramatically reduce bandwidth costs.

The work has been deployed imageproxy side, so we cap images by default, but clients can override the default if they need higher res. However, any blog post image on condenser will still be cached at the uncapped size, so this branch makes sure that the URLs are formatted such that they're rendered and cached at the capped size.

This change is easily reversible in case we wish to roll back this behavior later, by simply reverting the commit and re-deploying condenser.

So it is a change to save bandwidth for the user (you said 581 vs. 83 KB - that's a lot) and not to reduce their costs

Sort:  

Excellent research! Do you know why even when viewed at 640px (default Condenser size), severe compression artefacts are visible? Look at the image in this post on Steemit compared to Steempeak for example.
Downsizing images is a good idea, but not if there is a severe visible difference.

Actually I don't really know. Without any information, I would guess they use a shitty image resize/compression algorithm... They need to do that server side after all for a ton of images, and I guess that's why they went for a very fast solution, which, apparently, has too high payoffs.

Coin Marketplace

STEEM 0.17
TRX 0.24
JST 0.034
BTC 95527.71
ETH 2721.31
SBD 0.67