Do you mean under the new pact? That has a maximum of 30,000 a year I think (not an expert).

v3.0 of pyvips, the libvips binding for python, is out!

pypi.org/project/pyvi...

This release is much easier to install -- it's just `pip install pyvips[binary]` and it'll automatically download the right libvips for your platform. Linux / macOS / Win, x64 and arm64.

Have a look at eg:

github.com/jcupitt/buil...

Though I expect you know all this.

I made a nip2.app a long time ago:

github.com/jcupitt/buil...

and it includes the libvips dylib. It would need updating, but maybe there's something useful in there?

And the oldest bits of libvips are from 1989 o.O Though it's been mostly rewritten a couple of times in those 35 years, to be fair.

I sometimes start talks with "was anyone here born before 1989?" and there have been a few times where no one has raised a hand haha.

Release v9.0.1-3 · jcupitt/nip4 First public release A windows binary is in the assets tag below. For linux, there's a PR to add nip4 to flathub here: flathub/flathub#6166 You can install one of the test releases from that PR wit...

nip4 has a first test release!

github.com/jcupitt/nip4...

This is a rewrite of nip2 for the gtk4 UI toolkit. The backend is all the same, so it should run all old workspaces, but the UI is new and quite a bit slicker.

Any feedback would be very welcome!

- the underlying image processing library is pure, functional, and lazy, hence the low memory use
- the scripting language (dynamic Haskell with classes) is also pure, functional and lazy
- the GUI is built with gtk4, so it all renders on your GPU for smooth 60fps animations

nip4, the libvips image processing spreadsheet, is almost done!

www.libvips.org/2025/01/31/n...

It's correctly loading all the test workspaces I have, including a monster with 8.500 rows and 15,000 images.

I'm aiming for late Feb for a first alpha release.

I'll see if I can make a quick pyvips benchmark from that.

You shouldn't get libvips crashes, it's used on huge image proxies generating many millions of images an hour. I'd think a bug in the go binding (which we were not involved in) is more likely.

We should switch to github and make a tiny benchmark program with defined image sizes, formats, crop areas, resize ratios etc etc

Ah wait, do you just want to load complete JPEG images into GPU memory? Then you need a fast jpeg library (eg. libjpeg-turbo), and to run a decode on each core you have available. An image processing library probably probably won't help much.

It depends on the patch size. For small 32x32 pixel patches I got 25,000 / sec last time I tried:

github.com/libvips/pyvi...

But benchmarking is difficult. Before doing anything, you need a small program that accurately represents your expected use case.

It just picks one of these for you:

github.com/kleisauke/li...

so current stable libvips compiled to (almost) every combination of glibc / musl, x64 / arm32 / arm64, and linux / windows / macos.

The upcoming pyvips tries to fix this by automatically downloading a suitable libvips binary for you (just like sharp does on node). Though that's no help for you, of course :(

The core is here:

github.com/libvips/libv...

The rest of the C++ binding is mostly just convenience functions, overloads, stuff like that.

There's a chapter in the docs on binding:

www.libvips.org/API/current/...

tldr: Don't bind the main C API, bind the GObject API instead. The C++ binding might be a useful starting point -- it's only about 500 lines of code.

You could use pyvips, perhaps. It exposes the whole libvips API, and speed should be good.

Is that `DISC_THRESHOLD`? I don't think it's a security risk, is it? Filling server memory and causing a DoS might be worse.

I was sure I pressed reply :( I'm not good at bsky

bsky.app/profile/jcup...

We have a paper at IS&T in feb with some technical background and more detail, if you're interested:

www.southampton.ac.uk/~km2/papers/...

So for this image on this PC, libvips is about 5x faster and needs 10x less memory. You'll see similar results for PNG and TIFF, much worse for HEIC and AVIF heh.

They use the same lanczos3 resizing kernel, so quality should be identical.

You can compare speed and memory use like this:

$ /usr/bin/time -f %M:%e vipsthumbnail big.jpg --size 256x256 -o x.jpg
58180:0.20
$ /usr/bin/time -f %M:%e convert big.jpg -resize 256x256 x.jpg
717356:1.39

The output is peak memory use in kb, elapsed time in seconds. This is a 10k x 10k pixel JPG.

Sample C code here: github.com/libvips/libv...

Sorry, I've not used Go, you'll have to investigate.

You need to listen for the "eval" signal on the output image. It'll trigger for each work unit completed, with an ETA and percent-done.

www.libvips.org/API/current/...

There's also preeval and posteval for setup and teardown. You can call "kill" in the handler to cancel computation.

... to save you a click, on that test libvips is about 7x faster and needs 1/10th of the memory.

But it's a bit misleading -- libvips is threaded and opencv is largely unthreaded, plus that test is using TIFF images, which opencv does not handle quickly (in my experience).

Speed and memory use A fast image processing library with low memory needs. - libvips/libvips

There's a benchmark here comparing libvips to a range of other libraries, including opencv:

github.com/libvips/libv...

libvips does well on that test at least. It'd be much slower than opencv for more vision-like tasks, or on small images, but it can work well for basic image processing.

Issues · libvips/libvips A fast image processing library with low memory needs. - Issues · libvips/libvips

libvips author here. It uses the same resampling algorithm as imagemagick (lanczos3), so quality should be the same.

If you find a case where quality is different, please open a bug report with some sample images and the command that you ran:

github.com/libvips/libv...

darthsim is a good bloke, he did the improved JXL support in libvips 8.16, so he's certainly interested

Ooo, nice!

libvips 8.16.1 will have a policy for multipage JXL: if all frames have a duration of 0xffffffff, it's a many page still image; otherwise, it's animated.

Downstream libraries can handle the mixed case, if they dare.

OK, libvips 8.16 is out now, woo! It's finally someone else's responsibility if it doesn't work hehe