Re: [Gegl-developer] 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 > > ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] Returning to python-gegl
On 12 February 2015 at 16:30, Joao S. O. Bueno wrote: > Otherwise, I think I will rewire the python bindings using another > method to bridge to the C library, which is more predictive and better > supported. I've made a Python binding for my largish C library using gobject-introspection and not had any serious problems. It was a bit wonky a year or so ago, but it honestly seems OK now. Performance is good too, and I don't see any memory leaks. I'm very grateful for it. I've been trying to make a Ruby binding in the same way and oh dear oh dear it's a lot harder :( John ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] VIPS and GEGL performance and memory usage comparison
Hello all, vips maintainer here, thank you for this interesting discussion. On 29 January 2016 at 16:37, Daniel Rogers wrote: > A fast 8 bit pipeline is great for previews or single operation stacks, or > when accuracy is not as important for the user. My feeling is that gegl is probably right to be float-only, the cost is surprisingly low on modern machines. On my laptop, for that benchmark in 8-bit I see: $ time ./vips8.py tmp/x.tif tmp/x2.tif real0m0.504s user0m1.548s sys0m0.104s If I add "cast(float)" just after the load, and "cast(uchar)" just before the write, the whole thing runs as float and I see: $ time ./vips8.py tmp/x.tif tmp/x2.tif real0m0.578s user0m1.768s sys0m0.148s Plus float-only makes an opencl path much simpler. As you say, this tiny benchmark is very focused on batch performance, so fast startup / shutdown and lots of file IO. It's not what gegl is generally used for. John ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] VIPS and GEGL performance and memory usage comparison
On 2 February 2016 at 12:37, Øyvind Kolås wrote: > comparison. Adding a gegl:3x3-convolution (or adapting > gegl:convolution-matrix to detect the extent of the kernel) might make > GEGL perform closer to VIPS on this benchmark which caters well to > VIPS features. I do however not think we should add "hard-coded" 3x3 > sharpen/blur ops in GEGL. I agree, it's not very fair. I tried with gegl:convolution-matrix, but it was a lot slower, I'm not sure why. I realized that the tiff writer is writing float scRGBA, which is also not very fair. Is there a simple way to make it write a lower bit-depth image? Sorry for the stupid question. John ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] VIPS and GEGL performance and memory usage comparison
On 29 January 2016 at 19:07, Adam Bavier wrote: > numbers in that benchmark, I propose adding a asterisk * by each gegl number > would help the reader understand that something is different with this > library. Then add the corresponding asterisk down by the statement, "GEGL > is not really designed for batch-style processing -- it targets interactive > applications, like paint programs." Since gegl is the only interactive That's a good idea, thank you. I've updated the page with numbered notes by some results to make the qualifications easier to find. John ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
