stretch-contrast crash, Fourier transform, some questions.
This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| stretch-contrast crash, Fourier transform, some questions. | Håkon | 15 Aug 05:44 |
| stretch-contrast crash, Fourier transform, some questions. | Øyvind Kolås | 15 Sep 22:23 |
stretch-contrast crash, Fourier transform, some questions.
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:
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.
stretch-contrast crash, Fourier transform, some questions.
On 8/15/07, Håkon wrote:
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.
