RSS/Atom feed Twitter
Site is read-only, email is disabled

Gegl API calls vs. Gimp UI - different filter results

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.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

Gegl API calls vs. Gimp UI - different filter results Florian Klemme 24 Nov 16:20
  Gegl API calls vs. Gimp UI - different filter results Florian Klemme 17 Dec 22:06
Florian Klemme
2014-11-24 16:20:41 UTC (about 10 years ago)

Gegl API calls vs. Gimp UI - different filter results

Hi,

I am just starting out building some Gegl filters and I'm experiencing some problems with different results, depending on from where I invoke the filters. I'm using Ubuntu 14.04, Gegl from git (tagged 0.2.0), current babl from git (and Gimp 2.8 from the Ubuntu repository, just for testing purposes).

To test the results of my filters, I wrote a very simple program, which basically looks like this:

GeglNode *root = gegl_node_new(); GeglNode *load = gegl_node_new_child(root, "operation", "gegl:load", "path", "test_input.png", NULL);
GeglNode *test = gegl_node_new_child(root, "operation", test_operations[i], NULL);
GeglNode *save = gegl_node_new_child(root, "operation", "gegl:save", "path", output_filename, NULL);
gegl_node_link_many(load, test, save, NULL); gegl_node_process(save);

My first problem is that if I use this code, my output file resolution is increasing. When I run my filter and print out some debug information, I can see that the extra amount of pixels I request in my prepare function is already applied to the value of the result argument in my process function. The call to gegl_operation_get_required_for_output returns me an even larger rectangle.

This is a brief excerpt from my gegl filter code:

static void prepare(GeglOperation *operation) { GeglOperationAreaFilter *area = GEGL_OPERATION_AREA_FILTER(operation); GeglChantO *o = GEGL_CHANT_PROPERTIES(operation);

// Extra pixels needed in each direction area->left = area->right = 0;
area->top = area->bottom = o->height; // sloppy, but at least enough

gegl_operation_set_format(operation, "input", babl_format("RGB float"));
gegl_operation_set_format(operation, "output", babl_format("RGB float"));
}

process (...
const GeglRectangle *result, ...)
{
const GeglChantO *o = GEGL_CHANT_PROPERTIES(operation);

GeglRectangle source = gegl_operation_get_required_for_output(operation, "input", result);

g_print("result - x: %i, y: %i, width: %i, height: %i\n", result->x, result->y, result->width, result->height); g_print("source - x: %i, y: %i, width: %i, height: %i\n", source.x, source.y, source.width, source.height); ...

With the same input file (640 x 480), the same parameters and on the same machine...
A) Run with the program shown above: result - x: 0, y: -10, width: 256, height: 500 source - x: 0, y: -20, width: 256, height: 520 result - x: 256, y: -10, width: 384, height: 500 source - x: 256, y: -20, width: 384, height: 520 B) Run within Gimp via UI
result - x: 0, y: 0, width: 256, height: 480 source - x: 0, y: -10, width: 256, height: 500 result - x: 256, y: 0, width: 384, height: 480 source - x: 256, y: -10, width: 384, height: 500

Run with the program above, the output image will have an additional height of two times o->height (which is in this test cases always 10). The result are two (black) bars above and below the actual image. This problem does *not* occur when I run this filter within Gimp!

My second problem - but I don't care very much about this at the moment - is that the colors of the result are not quite the same as well, although I'm letting babl do all that work (I think). Because of the effect of the filter, the difference in brightness is quite easy to see.

I hope you have any idea that could help avoid the increase of *result / the output image in the first place. I appreciate every hint!

Regards, Florian

Florian Klemme
2014-12-17 22:06:49 UTC (almost 10 years ago)

Gegl API calls vs. Gimp UI - different filter results

Just to have this one closed: I've found the reasons of my problems. a) Height difference: This is actually intended by Gegl's area filter class. Just overload get_bounding_box an make it pass through the source bounding box to avoid any increases of your result rectangle size. b) Result difference: In this case, I had to use babl's R'G'B' instead of RGB.

_Florian

Am 24.11.2014 um 17:20 schrieb Florian Klemme:

Hi,

I am just starting out building some Gegl filters and I'm experiencing some problems with different results, depending on from where I invoke the filters. I'm using Ubuntu 14.04, Gegl from git (tagged 0.2.0), current babl from git (and Gimp 2.8 from the Ubuntu repository, just for testing purposes).

To test the results of my filters, I wrote a very simple program, which basically looks like this:

GeglNode *root = gegl_node_new(); GeglNode *load = gegl_node_new_child(root, "operation", "gegl:load", "path", "test_input.png", NULL);
GeglNode *test = gegl_node_new_child(root, "operation", test_operations[i], NULL);
GeglNode *save = gegl_node_new_child(root, "operation", "gegl:save", "path", output_filename, NULL);
gegl_node_link_many(load, test, save, NULL); gegl_node_process(save);

My first problem is that if I use this code, my output file resolution is increasing. When I run my filter and print out some debug information, I can see that the extra amount of pixels I request in my prepare function is already applied to the value of the result argument in my process function. The call to gegl_operation_get_required_for_output returns me an even larger rectangle.

This is a brief excerpt from my gegl filter code:

static void prepare(GeglOperation *operation) { GeglOperationAreaFilter *area = GEGL_OPERATION_AREA_FILTER(operation); GeglChantO *o = GEGL_CHANT_PROPERTIES(operation);

// Extra pixels needed in each direction area->left = area->right = 0;
area->top = area->bottom = o->height; // sloppy, but at least enough

gegl_operation_set_format(operation, "input", babl_format("RGB float"));
gegl_operation_set_format(operation, "output", babl_format("RGB float"));
}

process (...
const GeglRectangle *result, ...)
{
const GeglChantO *o = GEGL_CHANT_PROPERTIES(operation);

GeglRectangle source = gegl_operation_get_required_for_output(operation, "input", result);

g_print("result - x: %i, y: %i, width: %i, height: %i\n", result->x, result->y, result->width, result->height); g_print("source - x: %i, y: %i, width: %i, height: %i\n", source.x, source.y, source.width, source.height); ...

With the same input file (640 x 480), the same parameters and on the same machine...
A) Run with the program shown above: result - x: 0, y: -10, width: 256, height: 500 source - x: 0, y: -20, width: 256, height: 520 result - x: 256, y: -10, width: 384, height: 500 source - x: 256, y: -20, width: 384, height: 520 B) Run within Gimp via UI
result - x: 0, y: 0, width: 256, height: 480 source - x: 0, y: -10, width: 256, height: 500 result - x: 256, y: 0, width: 384, height: 480 source - x: 256, y: -10, width: 384, height: 500

Run with the program above, the output image will have an additional height of two times o->height (which is in this test cases always 10). The result are two (black) bars above and below the actual image. This problem does *not* occur when I run this filter within Gimp!

My second problem - but I don't care very much about this at the moment - is that the colors of the result are not quite the same as well, although I'm letting babl do all that work (I think). Because of the effect of the filter, the difference in brightness is quite easy to see.

I hope you have any idea that could help avoid the increase of *result / the output image in the first place. I appreciate every hint!

Regards, Florian
_______________________________________________ gegl-developer-list mailing list
List address: gegl-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gegl-developer-list