On 8/15/07, Håkon <haakhi@xxxxxxxxx> wrote: > <snip> > to stretch-contrast.c fixed it. This change has been committed. > - I'm trying to implement a Fourier transform filter in GEGL. It uses RGB > images with the real part of the complex numbers stored in red, and the > imaginary part in green. This should allow for some interesting things, like > implementing a frequency filter like this: Fourier processing is interesting, but not something I've put a lot of thought into myself. > - Some questions: > I guess storing complex data is a slight abuse of the RGB > model... Are there any caveats in having negative or > excessively large values in pixels? As long as it is not being passed through an operation that requests 8bit data there is no problem with neither negative nor very large RGB values, in fact this is explicitly supported to allow both high dynamic range imaging, as well as wide gamut RGB buffers. > Could one have pads other than 'input', 'aux' and 'output', for things like > composing/decomposing to channels? Yes, but then you can no longer use the nodes in the basic manner that is currently offered by the XML format. One operations that currently diverges from the normal set of inputs is operations/color/remap.c which takes three inputs. You'll also notice that this file is quite a bit more verbose, this is because it cannot use the preprocessor tricks employed by the more normal operations. To use such operations currently you have to construct the graph manually using the C/ruby/python APIs directly. The XML format should be extended to allow specifying "meta operations" (like drop-shadow and unsharp-mask) using XML files instead of .c files, the bug tracking this issue is: http://bugzilla.gnome.org/show_bug.cgi?id=465743 > Can you have several versions of a node, taking different formats? Currently not, at the moment each operation (the actual processing of the node) requests the data, and babl is used behind the scenes to convert the data to the desired format. At a later stage, multiple implementations of operations might be possible to register. > - I guess this is already known, but the GEGL tool > currently exports XML with a '/' erroneously prepended to > relative layer paths. The XML format isn't considered stable, but this sounds like a bug, could you please file a more throughout description of the issue in bugzilla? /Ø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 mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
