On 3/9/07, anton anton <ton4a@xxxxxxx> wrote: > I would like to improve performance or quality of image processing algorithms. Most such work is probably better if directed at GEGL[1] rather than GIMP. GEGL is a graph based image processing core developed to freeing GIMP from the restriction of 8bit per component and whilst doing that replacing almost, if not all, aspects of the GIMP that is modifying pixel buffers. The presentation I gave at FOSDEM this year[2][3], is the most recent and up-to date introduction to GEGL available. The public API of GEGL is now mostly settled, and bindings have started becoming available for Ruby, Python and C#. GEGLs public API is currently backed by a scaffolding providing for the features demanded by the public interface. The base for logging and reporting detailed timing instrumentation is already in place. The internal capabilities of GEGL are still being mapped out. The process of cleaning up the internal APIs is well under way and the next step are moving the architecture forwards with readable floating point reference implementations of operations, regression tested optimized SIMD and GPU versions of most or all operations as well as threaded and distributed processing. > 1) Algorithm optimization. For instance retinex in gimp work much more slowly than in my application. I can be mistake but your retinex use the same algorithm as my retiex and this difference in speed very strange. Another example white balance in gimp is not real white balance. As I know White balance should not change luminance. It only must change weight of each channel. There are some good ideas, which can be implemented in white balance. Retinex in GIMP might be slow, Porting your implementation of Retinex to be a GEGL operation, or implementing a new one for GEGL might fill the needs of some, other algortihms doing similar forms of automatic image enhancement are of course also interesting. > 2) I also can vectorize some algorithm with SIMD assembler instruction or other ways. I have some experience with such kind of optimization. > 3) I think gpu implementation of some filters can boost performance. I have not got experience with it, but it would be very very interesting to try. It would be interesting to makie some of the point-wise operations like porter duff compositing operators and arithmetic opertaions use SIMD/GPU. Do note that GEGL currently only contains 32bit floating point reference code and adding SIMD/GPU optimizations operating in 8bit/16bit whilst avoiding to trade off quality for speed depends on a build/run-time regression testing framework as well. > 4) Finally, may be good idea to make mathematic core, which perform common operations such as convolution+ GEGL itself lacks general a convolution operations (GIMP has a plug-in for parametrically controlled simple convolutions though). For components that are common between image processing algorithms it might even make sense to add internal APIs to gegl and on top of GeglBuffer or the tiles it can provide. /Øyvind K. 1: http://www.gegl.org/ 2: http://codecave.org/?weblog_id=fosdem2007 3: http://ftp.belnet.be/mirrors/FOSDEM/2007/FOSDEM2007-GEGL.ogg -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
