@jcupitt.bsky.social
Reposted
@ai6yr libvips is pretty magical. and avoids the umpteen CVEs that live in imagemagick due to it trying to process every format known to humans!
December 19, 2025 at 4:29 PM
@ai6yr libvips is pretty magical. and avoids the umpteen CVEs that live in imagemagick due to it trying to process every format known to humans!
Do you mean under the new pact? That has a maximum of 30,000 a year I think (not an expert).
May 15, 2025 at 10:27 AM
Do you mean under the new pact? That has a maximum of 30,000 a year I think (not an expert).
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?
github.com/jcupitt/buil...
and it includes the libvips dylib. It would need updating, but maybe there's something useful in there?
nip2.app
March 26, 2025 at 3:01 PM
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?
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.
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.
March 20, 2025 at 10:32 AM
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.
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.
- 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
- 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
February 1, 2025 at 12:34 PM
- 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
- 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
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.
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.
February 1, 2025 at 10:44 AM
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.
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
January 31, 2025 at 7:18 PM
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.
January 31, 2025 at 4:45 PM
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.
github.com/libvips/pyvi...
But benchmarking is difficult. Before doing anything, you need a small program that accurately represents your expected use case.
Most efficient region reading from tiled multi-resolution tiff images · Issue #100 · libvips/pyvips
Hi! This is not really an issue, but more of advice seeking. The context is that I am working with histopathological images (known as whole slide images) that have a typical size of 100k x 100k pix...
github.com
January 31, 2025 at 4:41 PM
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.
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.
github.com/kleisauke/li...
so current stable libvips compiled to (almost) every combination of glibc / musl, x64 / arm32 / arm64, and linux / windows / macos.
GitHub - kleisauke/libvips-packaging: Packaging scripts to prebuild libvips and its dependencies.
Packaging scripts to prebuild libvips and its dependencies. - kleisauke/libvips-packaging
github.com
January 31, 2025 at 4:36 PM
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.
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 :(
January 31, 2025 at 10:54 AM
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.
github.com/libvips/libv...
The rest of the C++ binding is mostly just convenience functions, overloads, stuff like that.
github.com
January 25, 2025 at 4:37 PM
The core is here:
github.com/libvips/libv...
The rest of the C++ binding is mostly just convenience functions, overloads, stuff like that.
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.
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.
libvips
A fast image processing library with low memory needs.
www.libvips.org
January 25, 2025 at 4:34 PM
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.
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.
January 22, 2025 at 10:12 AM
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.
January 21, 2025 at 5:45 PM
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.
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.
$ /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.
December 16, 2024 at 4:29 PM
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/...
www.southampton.ac.uk/~km2/papers/...
www.southampton.ac.uk
December 16, 2024 at 4:23 PM
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/...
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.
They use the same lanczos3 resizing kernel, so quality should be identical.
December 16, 2024 at 4:20 PM
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.
They use the same lanczos3 resizing kernel, so quality should be identical.