search

h2non / imaginary

Fast, simple, scalable, Docker-ready HTTP microservice for high-level image processing
https://fly.io/docs/app-guides/run-a-global-image-service/
MIT License
5.49k stars 452 forks source link

Fail gracefully when `format=auto` #309

Open mrkurt opened 4 years ago

mrkurt commented 4 years ago

We're seeing images that fail on webp encoding, but work fine with just jpg. The actual issue is #270.

Is it possible to make imaginary fail gracefully and just return the jpeg data it has when this kind of error happens?

h2non commented 4 years ago

270 is fixed in v1.2.0, which uses bimg v1.1.0, by fallback to a default ICC profile if no one is specified.

I will keep this issue open since it is still room for future improvement in the API behavior about the underlying idea of smarter format detection mechanism by inferring accepted image using Client Hints HTTP headers.

h2non commented 4 years ago

Related feature proposal: #253

n1bs commented 4 years ago

Hello,

We seems facing same kind of problem. When trying to convert JPEG (160px x 21600px) into WebP - getting HTTP400 with this inside: {"message":"Error while processing the image: vips2webp: unable to encode","status":400}

Would be great to fallback into JPEG in such cases instead of error.

In our case we send requests with explicit type=webp in query string.

h2non commented 4 years ago

Hello @n1bs! Can you provide some WebP image that is giving you trouble so I can reproduce? I assume you are running the v1.2.2.

A fallback mechanism might be optimal in this case, but I'd rather prefer this behavior to be explicitly requested in the HTTP request contract.

Something like overloading the current type query param to host multiple allowed formats with order preference could work nicely here: type=webp,jpeg.

Would that work?

mrkurt commented 4 years ago

I managed to replicate this with a random jpeg: https://i.imgur.com/6gBwEjy.jpg

The imaginary params were: /convert?url=https://i.imgur.com/6gBwEjy.jpg&stripmeta=true&type=webp&quality=80

Type with multiple available formats would work great for me.

n1bs commented 4 years ago

thanks for the test image, Kurt!

@h2non thanks for the quick look into this! Just to confirm - we're running v1.2.2 and type=webp,jpeg would work great for us.

h2non commented 4 years ago

Cool, I will try to ship this feature by the end of the week or early next week. Will keep things posted here!

h2non commented 4 years ago

A fix was pushed in v1.2.3 under Docker image tags latest, 1, and 1.2.3.

There is no change required in terms of URL API consumption. In case the image encoding fails, it will transparently fall back to JPEG encoding.

You can test it with: /convert?url=https://i.imgur.com/6gBwEjy.jpg&stripmeta=true&type=webp&quality=80