Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Large thumbnails undershoot the requested size #5302

Open
ara4n opened this issue May 31, 2019 · 4 comments
Open

Large thumbnails undershoot the requested size #5302

ara4n opened this issue May 31, 2019 · 4 comments
Labels
A-Media-Repository Uploading, downloading images and video, thumbnailing A-Spec-Compliance places where synapse does not conform to the spec O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.

Comments

@ara4n
Copy link
Member

ara4n commented May 31, 2019

If you request a larger thumbnail size than the largest precalculated thumbnail, you'll get the largest precalculated thumbnail, which could significantly undershoot the requested size.

This will end up looking horrible and blurry as the client then scales up the thumbnail to the size it asked for.

In Riot/Web (as of matrix-org/matrix-react-sdk#2439) we explicitly ask for the original image if the thumbnail exceeds 800x600, but we might do better to handle this more intelligently. Perhaps the solution is just to pregenerate even bigger thumbnails? Or default to serving the original image?

@ara4n
Copy link
Member Author

ara4n commented May 31, 2019

see also #1222

@deepbluev7
Copy link
Contributor

Is there any progress on this? I just hit that issue in nheko, which relies on the server thumbnailing a cropped image of 128x128 for some avatars. Some servers only return 96x96 cropped (since that is the recommendation in the spec). From reading the spec, specifically "Servers MUST NOT return a smaller thumbnail than requested, unless the original content makes that impossible.", I thought I would just get the original image in the worst case. I'd say the current behavior is a bug in synapse, but if I'm wrong, I will have to implement a fallback in nheko... The current behavior seems to be quite a pitfall for clients in any case.

@bwindels
Copy link
Contributor

bwindels commented Aug 3, 2021

Note that to be able to expect this from all HS implementations, this would require a spec change, currently it says:

Servers SHOULD produce thumbnails with the following dimensions and methods:

32x32, crop
96x96, crop
320x240, scale
640x480, scale
800x600, scale

@reivilibre
Copy link
Contributor

It seems very clear that the dimensions must match or exceed those asked for by the client unless the original is smaller (this is also mentioned in the description of the width and height query string parameters.

Servers must never return thumbnails smaller than the client's requested dimensions, unless the content being thumbnailed is smaller than the dimensions. When the content is smaller than the requested dimensions, servers should return the original content rather than thumbnail it.

(emphasis mine)

As such, this seems like a Synapse defect.

@reivilibre reivilibre added S-Minor Blocks non-critical functionality, workarounds exist. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. and removed z-enhancement labels Aug 3, 2021
@MadLittleMods MadLittleMods added the A-Media-Repository Uploading, downloading images and video, thumbnailing label Jun 10, 2022
@clokep clokep added A-Spec-Compliance places where synapse does not conform to the spec O-Occasional Affects or can be seen by some users regularly or most users rarely and removed z-p2 (Deprecated Label) labels Oct 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Media-Repository Uploading, downloading images and video, thumbnailing A-Spec-Compliance places where synapse does not conform to the spec O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.
Projects
None yet
Development

No branches or pull requests

7 participants