Fail gracefully when format=auto

[mrkurt]

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]

#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]

Related feature proposal: #253

[n1bs]

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]

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]

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]

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]

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

[h2non]

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