Lovell Fuller

The performance of the "brute force" example you've linked to could be improved, or at least made more consistent, with the use of binary search. Given most lossy image encoding...

Thanks for reporting, commit https://github.com/lovell/sharp/commit/397ee492d922e2bc9c871ae964bfe440f582ce07 fixes this and adds these dimensions as a test case that would previously have failed.

v0.33.4 now available.

This looks highly specific to a particular scenario and feels like it belongs in a consumer of sharp rather than sharp itself.

Your approach to calculate these values looks correct and matches the advice previously given at https://github.com/lovell/sharp/issues/3696#issuecomment-1587898783 I'm unsure if this logic needs adding to and therefore fall under the maintenance...

Closing as I'm not keen to add this logic to sharp itself - all the data required to calculate this is already exposed.

You've not provided an example image but the `lineArt` property may be more appropriate for your input images. https://sharp.pixelplumbing.com/api-resize#trim ```js .trim({ lineArt: true }) ```

> What is the impact on performance of `lineArt: true` I would expect minimal, it might be very slightly faster, you'll need to profile using samples of the type of...

If the input is best represented as in a vector format such as SVG or uses a lossless compression such as PNG then `lineArt` would be more suitable as there...

I hope this information helped. Please feel free to re-open with more details if further assistance is required.