On Tue, Apr 10, 2012 at 11:12 PM, johannes hanika hana...@gmail.com wrote:
actually darktable's pixel pipeline was based on gegl as the project
started (you'll still notice some #ifdef HAVE_GEGL if you look around
the code closely). that was 2-3 years ago and at that time it turned
out a simple DIY pipeline was a lot faster, to a point where it just
didn't seem practicable to use gegl. that said i love the clean gegl
api and would totally love to see dt/gimp use the same rendering api
and have some compatible interchange format.
It is not surprising that doing a DIY pipeline would give faster
results more immediately, for the first few years after I took up
maintainership of the then derelict GEGL project my previous graph
based full image compositor gggl continued to run circles around GEGL
but slowly as GEGL matured it has gotten better - your concerns are
due to things that are not completed - contributions are as always
most welcome (note that for features like demosaicing GEGL has very
naive support currently; and even if someone wanted to port for
instance more advanced/alternative demosaicing from Darktable - they
would not be able to since GEGL is LGPL).
i guess the biggest issues back then were:
- processing the image as a whole, not just the region of interest at
the currently visible scale. darktable pre-downsamples and processes
only these pixels (comes with issues, mostly works fine).
- i had the feeling that even resampling the image to these small
tiles came with a huge overhead
Doing it with a scale node would be slow, using the built in
mechanisms to generate mip-maps in GeglBuffer would fast. The plan for
GEGL has been to do previews rendering of the current visible scale
directly on these mip-map levels; contributions in that area would be
most welcome. The support is not complete but hopefully most of the
API changes neccesary landed in GEGL 0.2.0 which GIMP-2.8 depends on.
GIMP will not be able to make use of such snappier compositing and
preview using GEGL until close to the end of the 2.10 cycle when all
drawables are native GeglBuffers.
- easy to insert a cache (we cache the input to the plugin the user is
currently tweaking for example).
GEGL has had caches in the pipeline; some automatic as well as the
ability to forcibly opt in and out of caching.
- we have esoteric pixel formats (bayer patterns, in 16-bit and in
32-bit float, etc.).
GEGL supports any pixel format supported by babl, this includes 16bit
and 32bit integer as well as floating point. Demosaicing such bayer
patterns is also well within the scope of GEGL.
In the end doing a single chained pipeline processor with GEGL should
not be much code and it should end up being fast. It is just taking
longer to get there because GIMP has been slow in it's own adoption of
GEGL and it seems like most projects prefer to put together the
simplest thing that possibly can work and grow their own custom
solution from that instead of adopting and helping out with a common
infrastructure.
With the recent goat-invasion of GIMP the future for GEGL is
brightening up and I have hopes that GEGLs momentum and adoption will
finally be increasing and hopefully be able to sustain itself also
without me pushing it.
/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
___
gegl-developer-list mailing list
gegl-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gegl-developer-list
