search

amiv-eth / amivapi

The REST API behind most of AMIV's web services.
http://api.amiv.ethz.ch/docs
GNU Affero General Public License v3.0
31 stars 6 forks source link

Restricting image file size #390

Open Moschn opened 5 years ago

Moschn commented 5 years ago

Many events contain posters that are in the order of multiple megabytes. The current AMIV website downloads 14Mb of files, and all of the big files are images from events.

I think there are four solutions to this problem:

  1. Manually tell people to be careful about the file size
  2. The admin to validat tools could disallow big file sizes
  3. Add a validator rule to the APIe file size
  4. Add ImageMagick bindings to the API to automatically compress images

In my opinion, we should go with option 3 or 4.

NotSpecial commented 5 years ago

We already use ImageMagick, so 4 might be easy to implement..maybe using a query parameter, like compress?

NotSpecial commented 5 years ago

Additionally, caching for images should make sense, as noted by @temparus in #389 .

Moschn commented 5 years ago

I did not know that the API already uses ImageMagick. A compress query parameter would be a nice solution. Maybe even combined with a validator rule?

Caching would decrease the load on the server but the bandwidth to the user would not change. E.g., as a mobile user, I do not want to download 14mb every time I open the AMIV website and I do not really care if the image is cached or not.

NotSpecial commented 5 years ago

How do you imagine the validator rule? We do not want to force event people to store e.g. the poster anywhere else than in the API -- which file size would you recommend to not cause any problems?

And regarding your second point: It's true that the first time you open the website, you won't save data, but the website doesn't change that frequently, so I think it would save you bandwidth if the image is already cached.

Moschn commented 5 years ago

Ah you are talking about that kind of cache. This obviously makes sense...

I do not think that people would go somewhere else to store their images. If we enforce a rule of lets say 1Mb per image then only extremely large images will have issues. The biggest resolution we are talking about would maybe be 1920x1080 for the infoscreen and an uncompressed image with 32bit per pixel would be around 8Mb of size. I am convinced that losless compression on any poster would lead to a file size of less than 1Mb. If the users are unable to compress it themselves, we can point them to the compress option.