Support resizing of local avatars #9449

New Issue

GiteaMirror · 2025-11-02T08:39:11-06:00

GiteaMirror commented

2025-11-02 08:39:11 -06:00

Originally created by @somera on GitHub (Aug 22, 2022).

Description

When I see the size=84 parameter in the URL I think gitea should send 84x84 pixel big icon. But I see, that Gitea is sending 290x290 pixel big icon.

With 2000+ organizations it's need ~10 seconds, 2000+ requests and some MB's.

Gitea Version

1.17.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.25.1

Operating System

Ubuntu 20.04.4

How are you running Gitea?

Self hosted gitea-1.17.1-linux-amd64

Database

PostgreSQL

Originally created by @somera on GitHub (Aug 22, 2022). ### Description When I see the size=84 parameter in the URL I think gitea should send 84x84 pixel big icon. But I see, that Gitea is sending 290x290 pixel big icon. ![image](https://user-images.githubusercontent.com/8334250/186027608-52384147-abd2-4a07-8a81-2e319adb9455.png) With 2000+ organizations it's need ~10 seconds, 2000+ requests and some MB's. ![image](https://user-images.githubusercontent.com/8334250/186027828-91570f04-c903-4b27-b69f-cf7312413e7a.png) ### Gitea Version 1.17.1 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.25.1 ### Operating System Ubuntu 20.04.4 ### How are you running Gitea? Self hosted gitea-1.17.1-linux-amd64 ### Database PostgreSQL

GiteaMirror added the type/enhancement issue/confirmed labels 2025-11-02 08:39:11 -06:00

GiteaMirror commented

2025-11-02 08:39:12 -06:00

@silverwind commented on GitHub (Aug 23, 2022):

Yes, seems like a bug. The intention is for the server to send 84px in this case.

@silverwind commented on GitHub (Aug 23, 2022): Yes, seems like a bug. The intention is for the server to send 84px in this case.

GiteaMirror commented

2025-11-02 08:39:12 -06:00

@somera commented on GitHub (Aug 25, 2022):

A can't compare this to the 1.16.x version. But in the 1.16.x release loading a page with a lot of orgas war faster. Looks like new bug in 1.17.x.

@somera commented on GitHub (Aug 25, 2022): A can't compare this to the 1.16.x version. But in the 1.16.x release loading a page with a lot of orgas war faster. Looks like new bug in 1.17.x.

GiteaMirror commented

2025-11-02 08:39:12 -06:00

@lunny commented on GitHub (Aug 25, 2022):

But they will be cached?

@lunny commented on GitHub (Aug 25, 2022): But they will be cached?

GiteaMirror commented

2025-11-02 08:39:13 -06:00

@somera commented on GitHub (Aug 25, 2022):

But they will be cached?

Yes. But this is "strange". When I click in gitea I see "memory cached" and its fast.

When I try to migrate new project it slower (8-10 seconds) and I see "disk cache".

Tested with Chrome (Version 104.0.5112.102 (Offizieller Build) (64-Bit))

@somera commented on GitHub (Aug 25, 2022): > But they will be cached? Yes. But this is "strange". When I click in gitea I see "memory cached" and its fast. ![image](https://user-images.githubusercontent.com/8334250/186676899-705559c2-47b3-4f5f-95e3-ce0140ac98fc.png) When I try to migrate new project it slower (8-10 seconds) and I see "disk cache". ![image](https://user-images.githubusercontent.com/8334250/186676941-ad84c6c0-83cc-405e-acf6-df4b2b91ed0c.png) Tested with Chrome (Version 104.0.5112.102 (Offizieller Build) (64-Bit))

GiteaMirror commented

2025-11-02 08:39:13 -06:00

@silverwind commented on GitHub (Aug 25, 2022):

Not sure when a browser will decide to offload to disk, but we should probably make the hardcoded 5 minute cache duration on avatars configurable:

dc0253b063/routers/web/user/avatar.go (L18-L21)

@silverwind commented on GitHub (Aug 25, 2022): Not sure when a browser will decide to offload to disk, but we should probably make the hardcoded 5 minute cache duration on avatars configurable: https://github.com/go-gitea/gitea/blob/dc0253b0637bbf367ad330612900e780c6b2b0e6/routers/web/user/avatar.go#L18-L21

GiteaMirror commented

2025-11-02 08:39:14 -06:00

@silverwind commented on GitHub (Aug 25, 2022):

~~https://github.com/go-gitea/gitea/pull/20958 restores avatars to use STATIC_CACHE_TIME again which defaults to 6h so we can hit the cache much more than before.~~ Turns out it wasn't needed.

@silverwind commented on GitHub (Aug 25, 2022): ~~https://github.com/go-gitea/gitea/pull/20958 restores avatars to use STATIC_CACHE_TIME again which defaults to 6h so we can hit the cache much more than before.~~ Turns out it wasn't needed.

GiteaMirror commented

2025-11-02 08:39:14 -06:00

@silverwind commented on GitHub (Aug 25, 2022):

Back to this issue's topic: The problem is that the size argument only works for external avatar services like Gravatar. The local avatar handler ignores the size argument and always serves the full-size avatar from storage.

What needs to be done:

Make the /avatars/* request handler respect size and resize it.
Store the resulting images in server cache and invalidate this cache when a user/org updates their avatar.

(Can someone rename issue to "Support resizing of local avatars"? I can't)

@silverwind commented on GitHub (Aug 25, 2022): Back to this issue's topic: The problem is that the `size` argument only works for external avatar services like Gravatar. The local avatar handler ignores the `size` argument and always serves the full-size avatar from storage. What needs to be done: 1. Make the `/avatars/*` request handler respect `size` and [resize it](https://stackoverflow.com/a/22940904/808699). 2. Store the resulting images in server cache and invalidate this cache when a user/org updates their avatar. (Can someone rename issue to "Support resizing of local avatars"? I can't)

GiteaMirror commented

2025-11-02 08:39:14 -06:00

@somera commented on GitHub (Aug 25, 2022):

@silverwind I renamed it

@somera commented on GitHub (Aug 25, 2022): @silverwind I renamed it

GiteaMirror commented

2025-11-02 08:39:15 -06:00

@somera commented on GitHub (Sep 7, 2022):

Will be there a fix for the next (1.17.3 or 1.18.x) release?

@somera commented on GitHub (Sep 7, 2022): Will be there a fix for the next (1.17.3 or 1.18.x) release?

GiteaMirror commented

2025-11-02 08:39:15 -06:00

@somera commented on GitHub (Sep 9, 2022):

Status with 1.17.2 for the start page with 2192 organisations.

Chrome:

FF:

@somera commented on GitHub (Sep 9, 2022): Status with 1.17.2 for the start page with 2192 organisations. Chrome: ![image](https://user-images.githubusercontent.com/8334250/189454338-6238f2cc-be1a-47aa-b1dc-5b5d3cd5fcb8.png) FF: ![image](https://user-images.githubusercontent.com/8334250/189454334-87663a99-fd44-4f74-b07f-357172243478.png)

GiteaMirror commented

2025-11-02 08:39:15 -06:00

@somera commented on GitHub (Sep 10, 2022):

I took a look on Gitea 1.16.x. This version has the same scale bug.

But I thin that with my gitea usage (generating a lot of organizations) I reached some subability and load time limitations. Just create on you local instances ~2000 orgas for see what I mean. On gitea.com are ~1140 orgas. If you log there with admin permissions than you could analyze my experience with the loading time.

When I want create a new repo or mirror in specific orga, than you don't need load all orgas in the following pages.

This make no sense for me.

Why there is an icon needed in the drop list?
On the start page there is a search field for repos. But not for orgas. All orgs will be loades.

This is not consistent.

On the start page the drop-down list with orgas is not a good idea if you have a lot otf them. In this case the search box in 3. will be a better solution.

@somera commented on GitHub (Sep 10, 2022): I took a look on Gitea 1.16.x. This version has the same scale bug. But I thin that with my gitea usage (generating a lot of organizations) I reached some subability and load time limitations. Just create on you local instances ~2000 orgas for see what I mean. On gitea.com are ~1140 orgas. If you log there with admin permissions than you could analyze my experience with the loading time. 1. When I want create a new repo or mirror in specific orga, than you don't need load all orgas in the following pages. ![image](https://user-images.githubusercontent.com/8334250/189499402-907e3276-d5ab-42ad-8de6-ce62177a126a.png) This make no sense for me. 2. Why there is an icon needed in the drop list? 3. On the start page there is a search field for repos. But not for orgas. All orgs will be loades. ![image](https://user-images.githubusercontent.com/8334250/189499477-b808691d-b3d1-4bd6-ab97-6e534e65b192.png) ![image](https://user-images.githubusercontent.com/8334250/189499479-57527d42-9380-41fe-8a3b-ec40e1377c8c.png) This is not consistent. 4. On the start page the drop-down list with orgas is not a good idea if you have a lot otf them. In this case the search box in 3. will be a better solution. ![image](https://user-images.githubusercontent.com/8334250/189499524-341aa6a3-5127-4c68-98de-6d6737906fef.png)

GiteaMirror commented

2025-11-02 08:39:16 -06:00

@somera commented on GitHub (Sep 11, 2022):

I have one idea to solve this problem for the avatar url calls. Just add new property:

[picture]
ENABLE_AVATAR_IN_LISTS = false -> default is 'true'

Is this set to false, than in all lists (start page/issues/pull requests/milestones, new repo/mirror) the avatar image url in the select list will be not shown. And the scale bug should be fixed to.

@silverwind I wanted add an nginx proxy with image scaling/caching. But I found that the scale size don't correspond to the rendered sice in the browser. Some examples.

@somera commented on GitHub (Sep 11, 2022): I have one idea to solve this problem for the avatar url calls. Just add new property: ``` [picture] ENABLE_AVATAR_IN_LISTS = false -> default is 'true' ``` Is this set to false, than in all lists (start page/issues/pull requests/milestones, new repo/mirror) the avatar image url in the select list will be not shown. And the scale bug should be fixed to. @silverwind I wanted add an nginx proxy with image scaling/caching. But I found that the scale size don't correspond to the rendered sice in the browser. Some examples. ![image](https://user-images.githubusercontent.com/8334250/189546450-af6bd5a8-6fe8-4741-9289-6b2fd77dc908.png) ![image](https://user-images.githubusercontent.com/8334250/189546457-8a50f84e-5382-4221-98c4-f799b17c9db8.png) ![image](https://user-images.githubusercontent.com/8334250/189546460-4db5cccd-fe2c-40fe-ae24-ae753dd49125.png) ![image](https://user-images.githubusercontent.com/8334250/189546466-0cf8bebf-06bb-4002-b2a2-dfd62e9c153f.png) ![image](https://user-images.githubusercontent.com/8334250/189546468-aafc019c-3d8b-4308-9d5e-4fdcd0d92cb6.png) ![image](https://user-images.githubusercontent.com/8334250/189546475-985c3ae3-5be7-4e7d-b92b-ea1d2da1d9bf.png) ![image](https://user-images.githubusercontent.com/8334250/189552427-68c14d5e-b83b-4202-9220-4d2929244732.png)

GiteaMirror commented

2025-11-02 08:39:16 -06:00

@somera commented on GitHub (Oct 9, 2022):

Last days I installed Nginx as proxy and added avatar scaling. This is reducing only the amount of data which is sended to the client.

I see here two problems:

Chrome: sometimes is using memory cache. But more often the disc cache. And this is strage, what I can't understand.
Gitea: loading (long) list with organizations.

@somera commented on GitHub (Oct 9, 2022): Last days I installed Nginx as proxy and added avatar scaling. This is reducing only the amount of data which is sended to the client. I see here two problems: - Chrome: sometimes is using memory cache. But more often the disc cache. And this is strage, what I can't understand. - Gitea: loading (long) list with organizations.

GiteaMirror commented

2025-11-02 08:39:16 -06:00

@somera commented on GitHub (Oct 16, 2022):

@somera commented on GitHub (Oct 16, 2022): ![image](https://user-images.githubusercontent.com/8334250/196056911-bbb37f6e-5ec7-42c9-a5af-8d587f8cb90a.png)

GiteaMirror commented

2025-11-02 08:39:17 -06:00

@somera commented on GitHub (Oct 18, 2023):

I have now an nginx proxy with working scaling. Cause my gitea with 3200 avatars is "slow".

/etc/nginx/nginx.conf:

http {
    map $request_uri $width {
        default 28;
        ~\?size=512 512;
        ~\?size=420 420;
        ~\?size=280 280;
        ~\?size=140 140;
        ~\?size=100 100;
        ~\?size=84 84;
        ~\?size=72 72;
        ~\?size=56 56;
        ~\?size=48 48;
        ~\?size=45 45;
        ~\?size=40 40;
        ~\?size=28 28;
        ~\?size=24 24;
    }
}

/etc/nginx/conf.d/gitea.conf:

server {
    location ~ "^/git/avatars/(?<image>[0-9a-f]+)$" {
        # nginx user is added to the git group and
        # /usr/share/nginx/gitea_avatars_current is a soft link to /var/lib/gitea/data/avatars
        alias /usr/share/nginx/gitea_avatars_current/$image;

        proxy_cache_key "$image$width";
        proxy_cache nginx_cache;
        proxy_cache_valid any 60m;
        add_header X-Proxy-Cache $upstream_cache_status;
        add_header X-Avatar-Filename $image;
        add_header X-Avatar-Width $width;
        add_header Cache-Control "public, max-age=600";

        image_filter test;
        image_filter_jpeg_quality 75;
        image_filter resize $width -;

        access_log /var/log/nginx/gitea_avatars.access.log;
        error_log /var/log/nginx/gitea_avatars.error.log error;
    }

    # Note: Trailing slash
    location /git/ {
        client_max_body_size 364M;

        # Note: Trailing slash
        proxy_pass http://localhost:3000/;

        proxy_connect_timeout 600;
        proxy_send_timeout 600;
        proxy_read_timeout 600;

        send_timeout 600;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        access_log /var/log/nginx/gitea.access.log;
        error_log /var/log/nginx/gitea.error.log error;
    }

    location /git/_/static/assets/ {
        alias /usr/share/nginx/gitea_public/;

        proxy_cache nginx_cache;
        proxy_cache_valid any 60m;
        add_header X-Proxy-Cache $upstream_cache_status;

        access_log /var/log/nginx/gitea_public.access.log;
        error_log /var/log/nginx/gitea_public.error.log error;
    }
}

Should this stay open? For me, can this be closed.

@somera commented on GitHub (Oct 18, 2023): I have now an nginx proxy with working scaling. Cause my gitea with 3200 avatars is "slow". /etc/nginx/nginx.conf: ``` http { map $request_uri $width { default 28; ~\?size=512 512; ~\?size=420 420; ~\?size=280 280; ~\?size=140 140; ~\?size=100 100; ~\?size=84 84; ~\?size=72 72; ~\?size=56 56; ~\?size=48 48; ~\?size=45 45; ~\?size=40 40; ~\?size=28 28; ~\?size=24 24; } } ``` /etc/nginx/conf.d/gitea.conf: ``` server { location ~ "^/git/avatars/(?<image>[0-9a-f]+)$" { # nginx user is added to the git group and # /usr/share/nginx/gitea_avatars_current is a soft link to /var/lib/gitea/data/avatars alias /usr/share/nginx/gitea_avatars_current/$image; proxy_cache_key "$image$width"; proxy_cache nginx_cache; proxy_cache_valid any 60m; add_header X-Proxy-Cache $upstream_cache_status; add_header X-Avatar-Filename $image; add_header X-Avatar-Width $width; add_header Cache-Control "public, max-age=600"; image_filter test; image_filter_jpeg_quality 75; image_filter resize $width -; access_log /var/log/nginx/gitea_avatars.access.log; error_log /var/log/nginx/gitea_avatars.error.log error; } # Note: Trailing slash location /git/ { client_max_body_size 364M; # Note: Trailing slash proxy_pass http://localhost:3000/; proxy_connect_timeout 600; proxy_send_timeout 600; proxy_read_timeout 600; send_timeout 600; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; access_log /var/log/nginx/gitea.access.log; error_log /var/log/nginx/gitea.error.log error; } location /git/_/static/assets/ { alias /usr/share/nginx/gitea_public/; proxy_cache nginx_cache; proxy_cache_valid any 60m; add_header X-Proxy-Cache $upstream_cache_status; access_log /var/log/nginx/gitea_public.access.log; error_log /var/log/nginx/gitea_public.error.log error; } } ``` Should this stay open? For me, can this be closed.

GiteaMirror commented

2025-11-02 08:39:17 -06:00

@silverwind commented on GitHub (Oct 18, 2023):

Keep it open, we still want to fix this and implement resizing on upload and ideally resize any existing oversized avatars.

@silverwind commented on GitHub (Oct 18, 2023): Keep it open, we still want to fix this and implement resizing on upload and ideally resize any existing oversized avatars.

GiteaMirror commented

2025-11-02 08:39:17 -06:00

@SrAquaGenius commented on GitHub (Apr 3, 2024):

Hi, while trying to solve this issue, I have some questions:

What is the functionality of RenderedSizeFactor, defined in picture.go and equal to 2.
That can explain why some avatars/url-size are in one-to-two ratio.
The maximum avatar width (and height) is 4096. Isn't that unnecessarily big?
Where exactly is the avatar request handler?
Finally, different views have different avatars sizes. Is it worth saving all of them?

I am also interested in coding avatar resizing availability as a new feature!
Greetings

@SrAquaGenius commented on GitHub (Apr 3, 2024): Hi, while trying to solve this issue, I have some questions: - What is the functionality of **RenderedSizeFactor**, defined in [picture.go](https://github.com/go-gitea/gitea/blob/main/modules/setting/picture.go#L16) and equal to 2. That can explain why some avatars/url-size are in one-to-two ratio. - The maximum avatar width (and height) is 4096. Isn't that unnecessarily big? - Where exactly is the avatar request handler? - Finally, different views have different avatars sizes. Is it worth saving all of them? I am also interested in coding avatar resizing availability as a new feature! Greetings

GiteaMirror commented

2025-11-02 08:39:18 -06:00

@somera commented on GitHub (Aug 7, 2024):

Hi, while trying to solve this issue, I have some questions:

Who can answer this questions?

What is the functionality of RenderedSizeFactor, defined in picture.go and equal to 2.
That can explain why some avatars/url-size are in one-to-two ratio.

The maximum avatar width (and height) is 4096. Isn't that unnecessarily big?

Ups ... I would say: too big!

Where exactly is the avatar request handler?

Finally, different views have different avatars sizes. Is it worth saving all of them?

I would say: yes!

In my solution with nginx I store every requested size. And this solution works fast.

I am also interested in coding avatar resizing availability as a new feature! Greetings

@somera commented on GitHub (Aug 7, 2024): > Hi, while trying to solve this issue, I have some questions: Who can answer this questions? > > * What is the functionality of **RenderedSizeFactor**, defined in [picture.go](https://github.com/go-gitea/gitea/blob/main/modules/setting/picture.go#L16) and equal to 2. > That can explain why some avatars/url-size are in one-to-two ratio. > * The maximum avatar width (and height) is 4096. Isn't that unnecessarily big? Ups ... I would say: too big! > * Where exactly is the avatar request handler? > * Finally, different views have different avatars sizes. Is it worth saving all of them? I would say: yes! In my solution with nginx I store every requested size. And this solution works fast. > > I am also interested in coding avatar resizing availability as a new feature! Greetings

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9449