On 3/9/07, anton anton 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

On Sat, Mar 10, 2007 at 03:34:28AM +0100, Øyvind Kolås wrote:

On 3/9/07, anton anton 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.

I'm not a programmer but seems to me that at this point the GEGL improving/developing and the integration in/with GIMP is paramount.

Why not to propose something in this field?

bye

Anton Slesarev wrote:

I would like to improve performance or quality of image processing algorithms. Try to describe some specific targets. [...]

Hi Anton,

I think all of these are good ideas, to varying degrees.

If you would like to do some of these things for SoC, it would be a good strategy to start doing things now if it is possible. Last year we got 10 times more applications than we could accept, and we found that our greatest difficulty was to tell the difference between people who had good ideas, and people who could actually implement those ideas and work effectively with the GIMP development system. To settle that question before the applications come in would give you a great advantage. Of course there would still not be any quarantee.

If you can, please visit the #gimp channel on irc.gimp.org for more discussion.

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu