libvips deliberately doesn't attempt to preserve image compression settings. It's not possible (with most image format libraries anyway) to do this correctly.
When you write an image, you have to say how you'd like it written (`--palette` for a palette PNG, for example).
Where the medieval London bridge was, about 30m east of the current London Bridge. You can see the line in the current street layout -- follow Gracechurch Street due South past The Monument.
Hello, libvips dev here, I'd trim down the dependencies. You're adding support for a lot of formats you won't need, and with loaders which are not tested with untrusted input.
You can also set the env var `VIPS_BLOCK_UNTRUSTED` and libvips will block unsafe loaders at runtime.
Well done! I'm a little puzzled by the libvips version though, is that correct? 8.14 is three years old. Debian trixie is on 8.16, and current stable libvips is 8.18.
libvips 8.18 is out!
github.com/libvips/libv...
The release notes are here:
www.libvips.org/2025/12/04/W...
The headline features are support for UltraHDR, camera RAW images, and Oklab/Oklch colourspace. Thanks and congratulations to all contributors!
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.
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.
