About GIFs on Medium
This is an email I sent to yourfriends@medium.com. I’m making it into an open letter in case anyone else is struggling with GIFs and is searching for answers about issues with uploading them.
Edit: As of July 15, all these issues are resolved! Even all the example images in this article are now GIFs, thanks to this letter and quick response from Medium. You guys are the best!
Hi Medium,
First of all, love your platform! I’ve started doing an image-heavy publication called Retronator Magazine and Medium does an amazing job!
Except for GIFs.
My latest Artist Feature consists almost exclusively of GIFs (since that is the artist’s body of work) so I have a great use case of seeing how your GIF to video conversion performs. Please forward this to your engineering team for consideration.
First of all, in your FAQ you inform us that the limit for GIFs is 3MB. However, uploading many GIFs under 3MB fail.
The reason why they fail is that you are re-saving the GIFs on your server without any optimization, which can result in files much larger than 3MB, so you reject them. GIFs have the ability to provide only difference between image frames (deltas) and potentially greatly reduce the file size. I understand you need full frame data when you feed the GIFs to your conversion utility, but you can do this in-memory before each conversion and discard it afterwards. Keep the user’s source GIFs for storage and display during editing. That way you are not confusing the user when they upload files smaller than 3MB and they fail for an unknown reason (unless you do as much research as I did).
Second thing, to reduce transfer file size to the client, you are converting the GIFs into MP4s for bigger compression gains. However, you are doing this very aggressively and only keeping the first frame as the keyframe of the video. This makes even some 3 frame videos (with big changes) to degrade, while all of them suffer linear regression towards the end of the video. The last part is often very blurred and provides a noticeable jump when the video loops.
Another undesirable result is that the page takes a heavy CPU/GPU load to render at all times. Browsers know to only render GIFs when they are actually visible, but if you’re playing movies, due to potential sound playing, they must be playing (and decoding) them all the time. So while you’re saving data transfer time, you’re not saving anyone’s battery life by doing the conversion. This might not apply to the Medium App, but it does for the webpage and assuming you’re on wi-fi, the gain in smaller transfer size is outweighed by the higher drain on your battery. Honestly, all of this is highly superficial since in 2015 even on a mobile data connection it doesn’t make much difference if you’re transferring 0.2MB vs 1MB of data, nor will 99.9% of users have a Medium article open with 30 GIFs (like mine).
What it does matter though, is that the GIFs on Medium look awful.
In case you do care about transfer file size gains (at the cost of increased storage) I’m providing an analysis of some GIFs from my article for your reference. I calculate the transfer gain for the end user (since they need to download a smaller MP4 file than the source GIF) and the storage increase for Medium (converted GIF and MP4 size versus the source GIF):
Source GIF size: 734 KB
Medium stored GIF size: 1.9 MB
Medium served MP4 size: 157 KB
Client transfer: 21%
Medium storage: 280%
Source GIF size: 404 KB
Medium stored GIF size: 885 KB
Medium served MP4 size: 233 KB
Client transfer: 57%
Medium storage: 276%
Source GIF size: 2.6 MB
Medium stored GIF size: 2.7 MB
Medium served MP4 size: 252 KB
Client transfer: 9%
Medium storage: 113%
Source GIF size: 2.6 MB
Medium stored GIF size: 2.8 MB
Medium served MP4 size: 555 KB
Client transfer: 21%
Medium storage: 129%
Note that at their small display size used in this letter, the degradation is not really noticeable. Look at them in my original article, and you will understand what I mean.
So I will admit that you are saving a lot of transfer size with this technique (the cost to the client is anywhere from 10%-50% relative to the source GIF), especially in highly moving GIFs that can’t be optimized well with the frame deltas.
However, this comes at a big price of quality degradation. If you insist on using the videos, please at least use some variable-bitrate variant where the compression can adapt to the actual content of the video.
More importantly, do not store recompressed and unoptimized GIFs on your servers. That way the user’s GIF size is actually the controlling factor (less than 3MB) for upload.
I hope this has been informative enough for you to consider acting on it. I understand GIFs are probably the least important thing on your platform and I even agree that in 21st century they should die in favor of some less archaic lossless video format. But please apply these easy to do fixes which won’t affect 99% of your articles, but greatly improve that 1% or 0.01% which is crazy enough to showcase 30 GIF artworks in one article.
Thank you for an otherwise amazing platform and giving us the tools to take article writing and publishing into the future.
With best regards,
Matej Jan // Retronator
