Scale/Optimise Avatars to output size

Currently all avatars that are displayed are using the original uploaded file in its original size, so for displaying a 24x24 User Avatar we load a 500 KB File sometimes. Also we should look at optimising PNG and eventual WebP There is a huge potential on saving bandwidth and loading time :

For all solutions we should align avatar sizes (i found 24, 26, 32, 36 , etc.). Also resized avatars will help a lot with rendering performance as the browser doesn't need to do it anymore.

Potential solutions :

CDN

We use a CDN to route our traffic through for .com, might be a quick win for now.

Resize + Caching on the fly

Our Backend is capable on a routing basis to deliver different predefined sizes. As soon an avatar is created the file will be saved + cached.

Could be done also through NGINX http://nginx.org/en/docs/http/ngx_http_image_filter_module.html

We should be aware about cleaning up avatars, if new versions are uploaded etc. Also use only predefined sizes otherwise DDOS is easy.

Create them during upload

Do the creation of the different sizes during upload. Problematic with existing avatars.

changed the description

mentioned in issue gitlab-foss#33958 (moved)

Carrierwave (our Rails upload library) supports storing multiple sizes of an uploaded image, but depends on imagemagick to do this, which is not something we want to include in GitLab's omnibus package.

Nginx's ngx_http_image_filter_module depends on libgd (https://libgd.github.io/) which we're not currently including either.

If including libgd is an option, it may be possible to get carrierwave to use libgd + https://github.com/sdsykes/fastimage_resize to resize images instead of imagemagick. Carrierwave can likely be told to resize files on the fly if the requested size doesn't exist yet, which would solve the problem with existing avatars.

/cc @smcgivern @dzaporozhets @marin

Interesting idea! I think Carrierwave also supports https://github.com/seattlerb/image_science, which depends on FreeImage instead - that might be a third option.

(I have no idea about how easy FreeImage will be to package.)

@DouweM If we are to include an NGINX module, doesn't that limit everyone to using that web server? What will users with alternative web servers do?

As for libgd itself, it's license might be a real issue: https://github.com/libgd/libgd/blob/master/COPYING . It doesn't list the dependencies as well, so I would have to dig in to see what it depends on.

As for FreeImage, it is GPL2 license and it might be even harder to ship it so we should look into it as a last resort.

@marin Yeah, including an Nginx module is far from optimal, I would prefer to do this on the backend, in Carrierwave. But it looks like imagemagick, libgd and FreeImage all have their own packaging issues :(

@DouweM that is what makes this a challenge :) I don't think that Nginx module is a good option in any case. I am working in parallel with a lawyer to see what are our borders when it comes to GPL licensed libraries inside of the package. So the other libraries might be possible to use. The answer is not going to come fast though...

@marin take a look at https://github.com/minimagick/minimagick too. Its supported by Carrierwave and seems to work with http://www.graphicsmagick.org/ which should be MIT

Have to say that I am very impressed with http://www.graphicsmagick.org/, cannot remember the last time I had no trouble finding information about a library. It is very flexible so we can compile it with the things we need (saving on space and possible license conflicts). The license looks good enough to say that we can look into using this library (I would still send it to our lawyer for verification though).

I would say, go ahead into investigating whether we can use the rubygem in combination with graphicsmagick. If they do what we need, ping me so we can look into doing a test build.

@mydigitalself Shall we schedule automatically resizing avatars to sensible sizes using Carrierwave/MiniMagick/GraphicsMagick?

changed milestone to %Next 2-3 months in gitlab-foss

mentioned in merge request gitlab-foss!12503 (merged)

So what's the final option for a backend image library here?

mentioned in issue gitlab-foss#15661 (moved)

mentioned in merge request gitlab-foss!14497

moved from gitlab-foss#34364 (moved)