On 3/9/07, anton anton <[EMAIL PROTECTED]> 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

Reply via email to