Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify how thumbnailing is supposed to work #2060

Closed
turt2live opened this issue May 31, 2019 · 3 comments · Fixed by #2068
Closed

Clarify how thumbnailing is supposed to work #2060

turt2live opened this issue May 31, 2019 · 3 comments · Fixed by #2068
Assignees
Labels
clarification An area where the spec could do with being more explicit client-server Client-Server API

Comments

@turt2live
Copy link
Member

Particularly the methods: crop/scale

@turt2live turt2live added clarification An area where the spec could do with being more explicit client-server Client-Server API labels May 31, 2019
@turt2live turt2live added this to To add to spec in Matrix 1.0 workflow via automation May 31, 2019
@turt2live turt2live moved this from To add to spec to Clarifications TODO in Matrix 1.0 workflow May 31, 2019
@ara4n
Copy link
Member

ara4n commented May 31, 2019

The intention is that crop removes data to make the image approximately fit into the requested aspect ratio, and scale shrinks the image down (not adding background colour) to make the image approximately fit instead. It's the same difference as between pan & scan (crop) versus letterboxing (scale), for those familiar with the terms.

The server treats the dimensions provided as an aspect ratio, and then should provide an image at least as large as the requested dimensions. This approximation is to avoid DoS and let servers precalculate thumbnails for commonly requested dimension sizes.

It's worth noting that synapse currently gets this wrong; if you request a bigger thumbnail than the largest one it's precalculated, you get the largest thumbnail (matrix-org/synapse#5302) which may undershoot. Cropping apparently can also undershoot (matrix-org/synapse#1222). When you undershoot, the client has to scale up the resulting image, resulting in horrid blurriness artefacts.

@turt2live
Copy link
Member Author

How should the server handle being requested to give a thumbnail larger than the source material?

@ara4n
Copy link
Member

ara4n commented May 31, 2019

it should return the source material. if in cropped mode, it could also crop it to the requested aspect ratio.

ftr, i personally detest that all of width, height, crop & scale end up being hints at best, and so the client always has to assume that the server may have entirely ignored them. it makes it incredibly hard to produce an optimal performant and sharp UI.

one approach might be to formally spec the recommended pre-computed dimensions that a server should support, so that client developers at least know what they have to work with. In fact, this might have been better than the whole hint API in the first place - you'd just pass an enum for the shape you want, and you then know what you'll get, rather than the whole "make it look like you can ask for anything, but then disappoint" experience we have today.

however, i think we're stuck with this shape for now, and at least it gives some level of flexibility for people to experiment with other dimensions in future.

@turt2live turt2live self-assigned this Jun 3, 2019
@turt2live turt2live moved this from Clarifications TODO to In progress in Matrix 1.0 workflow Jun 3, 2019
turt2live added a commit that referenced this issue Jun 3, 2019
Matrix 1.0 workflow automation moved this from In progress to Done Jun 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the spec could do with being more explicit client-server Client-Server API
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

2 participants