VIPS library
This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| VIPS library | scl | 10 Nov 11:15 |
| VIPS library | Nicolas Robidoux | 10 Nov 11:39 |
| VIPS library | jcupitt@gmail.com | 10 Nov 17:08 |
VIPS library
Hi,
these days I was pointed to the [VIPS library].
It's an image processing library with a focus
on high performance and low memory consumption.
Given this it can address two basic requirements
of image editing software:
- working fastly, i.e. see the [GIMP product vision],
- increasing image size as result from increasing
camera sensor resolution.
VIPS' main features include i.e. a wide range of image file formats and colour formats, optional inclusion of LCMS, almost complete support for non-destructive editing and a great amount of [image-processing operations]. From a developers point of view a clever, low-memory architecture ('demand-driven' processing) and multi-threading are some points of it. It's open source and free under the LGPL 2.1.
I explicitly don't argue to make GEGL obsolete. My aim is to share this information with you. I already saw, 0yvind has dealed with VIPS and the topic came up here some times during the last years. Currently the only two points where I find hints to VIPS in GEGL are N. Robidoux' lowhalo and nohalo samplers. But perhaps the library can provide us more and can take some work from us by using it in GEGL or giving us some inspiration.
Kind regards,
Sven
[VIPS library: http://www.vips.ecs.soton.ac.uk/index.php?title=Libvips https://github.com/jcupitt/libvips
[GIMP product vision]: http://gui.gimp.org/index.php/Vision_briefing
[image-processing operations]:
http://www.vips.ecs.soton.ac.uk/supported/current/doc/html/libvips/index.html
VIPS library
Proof of concept attempt to have VIPS used as a backend for GEGL: https://github.com/jcupitt/gegl-vips.
Discussion of the topic at http://gimp.1065349.n5.nabble.com/gegl-vips-td29248.html.
My gut feeling is that although there is a lot of good code and architecture to be "poached" from the VIPS library, such integration is even more of a nonstarter now than it was then.
Bias warning: I am (or was) both a GEGL and VIPS dev and may have been the originator of the "VIPS as backend for GEGL" idea (don't remember).
VIPS library
A lot has changed since then. It'd be interesting to try the tests again with the latest versions of the two libraries.
I think my 2p would be:
GEGL is very focussed on interactive use and less interested in batch-style processing. VIPS is the other way around: you can use it for interactive work, but most effort has gone into making batch-style operations quick. By batch-style processing I mean start with a complete image on disc or in memory, run a series of pre-planned operations, finish with another complete image on disc or in memory.
If people want to use the convenient GEGL interface to do batch-style work, they would probably get a useful speed-up with gegl-vips. Back in the dark days of 0.1.6, gegl-vips was up to about 200x faster than GEGL for batch work, though I'm sure that's changed now.
For interactive editing applications (such as Gimp), vips would need some work. The missing feature is area invalidation. vips supports whole image invalidation (if you change something in an image, you can ask all downstream operations to drop cache and recalculate the whole thing) but has no support for area invalidation (change a small area, drop caches just for that area, recalculate just the affected part of the final image).
I do plan to add area invalidation at some point since I need it for the nip2 paintbox but it's probably a year or two off, unless someone volunteers.
John
On 10 November 2013 11:39, Nicolas Robidoux wrote:
Proof of concept attempt to have VIPS used as a backend for GEGL: https://github.com/jcupitt/gegl-vips.
Discussion of the topic at http://gimp.1065349.n5.nabble.com/gegl-vips-td29248.html.
My gut feeling is that although there is a lot of good code and architecture to be "poached" from the VIPS library, such integration is even more of a nonstarter now than it was then.
Bias warning: I am (or was) both a GEGL and VIPS dev and may have been the originator of the "VIPS as backend for GEGL" idea (don't remember).
_______________________________________________ gegl-developer-list mailing list
List address: gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
