https://www.rubydoc.info/gems/ruby-vips/Vips.block_untrusted

You can also set the env var `VIPS_BLOCK_UNTRUSTED`, which might be easier.

You can block or allow specific load operations, so you can limit format support to just the types you need:

https://www.rubydoc.info/gems/ruby-vips/Vips#block-class_met...

That might be even better.

There was a post on libvips.org about this a while ago:

https://www.libvips.org/2022/05/28/What's-new-in-8.13.html

And a note about it in the checklist for devs:

https://www.libvips.org/API/current/developer-checklist.html...

I've found jemalloc works best for long running libvips processes, fwiw.

- I'd consider adding support for libvips smartcrop, ICC colour management, HDR, image alpha

- can you join pipelines? you could have one making a background, one making a foreground, then composite them, for example

- your benchmarks don't measure peak memory use, it can be a useful thing to test, especially if people are processing large images (eg. the output of every modern smartphone sigh)

- have you benchmarked against nip4, the official libvips GUI? it has a CLI mode you can run with GNU parallel

- I agree, a CLI mode for your tool sounds useful

https://sharp.pixelplumbing.com/install/#prebuilt-binaries

it can sometimes need to compile the C++ shim that sits between node and libvips, but that's rare.

https://sharp.pixelplumbing.com/install/#prebuilt-binaries

It can usually also download a precompiled binary for the C++ shim that sits between node and libvips, but if your node / arch / etc. is not supported, it'll compile that (that's what the build.js file you linked does).

image = pyvips.Image.new_from_file(filename, access="sequential")

scale = min(200 / image.width, 200 / image.height)

thumbnail = image.colourspace("oklab").resize(scale).extract_bands(0, n=3)

rgbf = thumbnail.write_to_memory()

That'll stream the source image and make a RGBRGBRGB memory buffer of single precision floats. You could perhaps use kernel="linear" and avoid any ringing from lanczos3.

I think I would downsample in a linear light space, like scRGB. Averaging there means averaging photons, which will surely be better than OKLab. Maybe switch to OKLab for clustering. Though of course I've not tested it.

It includes support for UltraHDR (HDR and SDR in one JPEG file), camera RAW images, and the Oklab colourspace. This should all be coming to sharp in the next six month or so.

https://github.com/libvips/libvips/wiki/Speed-and-memory-use

`govips` was a pretty early binding and wasn't really done the libvips way. It doesn't expose all the operations or options, it's mostly done by hand, and there are a number of leaks and misfeatures.

It's been replaced by `vipsgen`:

https://github.com/cshum/vipsgen

Which is an automatically generated 100% binding. It should have the complete API, it should be very stable and leak-free, and it should be simple to maintain.

`autorot` is pretty expensive. You'll see much better performance if you flip x and y in your crop instead.

VipsImage *image = vips_image_new_from_file("something.jpg", "autorotate", TRUE, NULL);

and it'll flip it upright for you and remove any EXIF orientation tag. It isn't the default since it has (obviously) a large memory and cpu cost.

For simple resize and crop it's much better to use the exif tag to adjust the resize and crop parameters (the vipsthumbnail command does this).

libvips is fairly highly threaded and does a lot of alloc/free, so it's challenging for most heap implementations.

https://github.com/lovell/sharp/issues/955#issuecomment-5458...

(that specific graph is for switching from glib to the musl memory allocator, but jemalloc gives a very similar result)