On Tue, Apr 10, 2012 at 11:12 PM, johannes hanika <hanatos@xxxxxxxxx> 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@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gegl-developer-list
