Re: [Gegl-developer] stretch-contrast crash, Fourier transform, some questions.

[Øyvind Kolås]

On 8/15/07, Håkon [EMAIL PROTECTED] 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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

[Gegl-developer] stretch-contrast crash, Fourier transform, some questions.

[Håkon]

Hi,

- whenever I inserted stretch-contrast into a graph, GEGL would crash with
the error message
** ERROR **: file gegl-operation.c: line 648 (gegl_operation_get_target):
assertion failed: (format != NULL)

Adding

#define GEGL_CHANT_PREPARE

and

static void prepare (GeglOperation *operation,
 gpointer context_id)
{
  gegl_operation_set_format (operation, input, babl_format (RGBA
float));
  gegl_operation_set_format (operation, output, babl_format (RGBA
float));
}

to stretch-contrast.c fixed it.


- 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:
gegl
node operation='mono-mixer' red='1.0'/
node operation='fourier-transform' inverse='true'/
node operation='multiply'
node operation='load' path='lowpass.png'/
/node
node operation='fourier-transform'/
node operation='colorize' green='0'/
layer src='image.png'/
/gegl

I have put what I have got so far at http://folk.ntnu.no/hitland/gegl/ , in
case anyone is interested.
The current implementation has some
issues, the worst of which is that it doesn't use the fast Fourier
transform, and therefore is impractically slow for anything much
larger than around
128x128, and that my algorithm seems to be wrong anyway, as the images
it gives are shifted compared to the examples I find on the net. :-/
Both should be resolved by finding a suitable FFT library or code example to
use.


- 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?

Could one have pads other than 'input', 'aux' and 'output', for things
like composing/decomposing to channels?

Can you have several versions of a node, taking different formats?


- I guess this is already
known, but the GEGL tool currently exports XML with a '/' erroneously
prepended to relative layer paths.
___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer