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

Scaling Images #354

Open
lujobi opened this issue Feb 23, 2019 · 3 comments
Open

Scaling Images #354

lujobi opened this issue Feb 23, 2019 · 3 comments

Comments

@lujobi
Copy link
Contributor

lujobi commented Feb 23, 2019

As discussed with @temparus: A nice enhancement would be if the api would scale the images automatically to the expected ratio

@NotSpecial
Copy link
Contributor

Hello, and thank you for your issue. Could your or @temparus please provide some more details on the requirements and usecases?

It seems to me that this is mostly needed as a feature to send less data, correct? If I correctly recall a conversation with @temparus, this is intended to allow posters to be uploaded in large size for print, while automatically being downscaled for web view?

If this is correct, I would propose simply adding a automatically populated field (image)_compressed, e.g. img_poster_compressed:

  1. The *_compressed field would be read-only.
  2. When uploading an image, the API automatically computes a down-scaled version and stores it alongside the high resolution image.
  3. When requesting the images, clients can decide whether to use the link from e.g. img_poster or img_poster_compressed

This solution would be very simple to implement and not require any new resources, query parameters, etc.

However, I cannot tell if it would fit the requirements -- it would be great if you could provide some more details. Thanks!

@lujobi
Copy link
Contributor Author

lujobi commented Feb 23, 2019

Reading your answer, it came to my mind that this was exactly what we were talking about.
@temparus can surely give further information

@NotSpecial NotSpecial added this to the Version 3.0 milestone Feb 23, 2019
@NotSpecial
Copy link
Contributor

Thanks for your feedback, we'll look into implementing this then!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants