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.
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 |
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
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 enoughgegl_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: 500Run 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