webp save methods do not support 'target_size' parameter

[john-parton]

The webp API supports saving with a "target_size" parameter to limit the maximum size of the resulting file.

int target_size;        // if non-zero, set the desired target size in bytes.
                        // Takes precedence over the 'compression' parameter.

https://developers.google.com/speed/webp/docs/api

As far as I can tell, this isn't exposed in libvips (and consequently pyvips, the binding I am using.)

This is a useful feature for my use case. I preprocess images before they are sent to CloudFlare Images. They have specific limits for resolution, but also an overall limit for file size. In my case, I set images to be at most 6,000 x 6,000 pixels and am saving with Q=90. For the vast majority of images, that's fine, because the resulting image is usually significantly less than 10MB, but for some noisy images with difficult to compress features, it just barely goes over the 10MB boundary.

If I could just pass this in, I wouldn't have to worry about, but now I'm faced with having to either:

1. Lower my resolution and Q factor for all images
2. Check the resulting output size every time, and then adjust either the resolution or Q factor if it's in excess of 10MB.

I wouldn't really consider either of these to be a good solution.

[jcupitt]

Hello @john-parton,

You're right, libvips doesn't expose all the webp save options. I've never needed the save-as-size feature so I wasn't sure how useful it was. We should probably add it.

Your 2. option isn't that bad -- you can do a binary search and find a good Q factor in only a few iterations. I imagine libwebp is doing something like that internally.

[jcupitt]

... I made an enhancement issue for this #3824

[jcupitt]

Sample binary search code, in case you hadn't seen it #3815

[john-parton]

No, it actually doesn't seem to do a binary search. It uses additional data returned by the encoder. Looks like it does some sort of gradient search? My familiarity with the internals of webp is... bad.

Loop where it calculates Q: https://github.com/webmproject/libwebp/blob/24d7f9cb6ef1ef90a04d7b6c15d3477813f75ee0/src/enc/frame_enc.c#L660-L663

Actual function where it refines the estimate for Q: https://github.com/webmproject/libwebp/blob/24d7f9cb6ef1ef90a04d7b6c15d3477813f75ee0/src/enc/frame_enc.c#L66-L83

And then sort of philosophically, bolting a binary search on top is a bit of an abstraction inversion given the lower level library already implements this functionality.

I understand if it's not a design goal of libvips to expose ALL the options.

Finally, it turns out to be very hard to replicate this issue with my client code, so it might not end up being useful for me ultimately.