Re: [Gegl-developer] VIPS and GEGL performance and memory usage comparison

[jcupitt]

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] Returning to python-gegl

[jcupitt]

On 12 February 2015 at 16:30, Joao S. O. Bueno gwid...@mpc.com.br 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 library

[jcupitt]

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 nicolas.robid...@gmail.com 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