* Calvin Williamson <calvinw@xxxxxxxxxxxxxx> [040115 03:11]:
> On 14/01/04, Daniel Rogers wrote:
> >
> > Yes, but there is no reason not to have an image type that one doesn't
> > need a node to use. In which case, node-result images and in memory
> > images have very different requirements.
>
> Certainly. You dont need a node to use an image. That is
> not what I am saying.
>
> I think I just dont understand your notion of "image".
> Let me show you what I think they are with some specific
> examples. Then maybe you can say if the way you are thinking
> is different
>
> Ill just show how you might set up a projection stack
> for gimp using images and ops and gobject properties.
The API Calvin outlines here, is close to the idea I have of the
architecture, some things are in libgggl (the quick hack and slash
processing lib bauxite uses, which hopefully will be replaced with gegl)
display
\
> combine3
> / \
> L3 combine2
> / \
> L2 combine1
> / \
> L1 P
>
> GeglNode *combine1 = g_object_new(GEGL_TYPE_COMBINE_OP,
> "source1", P,
> "source2", L1,
> NULL);
> GeglNode *combine2 = g_object_new(GEGL_TYPE_COMBINE_OP,
> "source2", L2,
> NULL);
> GeglNode *combine3 = g_object_new(GEGL_TYPE_COMBINE_OP,
> "source2", L3,
> NULL);
>
> gegl_node_connect(combine2, "source1", combine1, "dest");
> gegl_node_connect(combine3, "source1", combine2, "dest");
>
> gegl_node_apply(combine3, "dest");
In libgggl it would be:
Gggl *gggl = gggl_new ();
int P, L1, L2, L3, combine1, combine2, combine3, display;
P = gggl_node_new_filter (gggl, "blank");
L1 = gggl_node_new_filter (gggl, "drawable");
gggl_attribute_set (gggl, L1, "imageptr", gggl_image_ptr);
L2 = gggl_node_new_filter (gggl, "drawable");
gggl_attribute_set (gggl, L2, "imageptr", gggl_image_ptr);
L3 = gggl_node_new_filter (gggl, "drawable");
gggl_attribute_set (gggl, L3, "imageptr", gggl_image_ptr);
combine1 = gggl_node_new_filter (gggl, "combine");
gggl_node_set_input (gggl, combine1, 0, P, 0);
gggl_node_set_input (gggl, combine1, 1, L1, 0);
/* node_id--' in_pad-' `-- source_node `-- source_pad */
combine2 = gggl_node_new_filter (gggl, "combine");
gggl_node_set_input (gggl, combine2, 0, combine1, 0);
gggl_node_set_input (gggl, combine2, 1, L2, 0);
combine3 = gggl_node_new_filter (gggl, "combine");
gggl_node_set_input (gggl, combine3, 0, combine2, 0);
gggl_node_set_input (gggl, combine3, 1, L3, 0);
display = gggl_node_new_filter (gggl, "display");
gggl_node_set_input (gggl, display, 0, combine3, 0);
/* this is the actual code I use at the moment,.. setting all display,
* save to video etc, as active
*/
gggl_clear_active (gggl);
gggl_set_active (gggl, display);
gggl_process (gggl);
I am going to start making libgggl dependant on libgegl pretty soon,.
and eventually libgggl will disappear from bauxite. At least that is my
migration plan.
One thing I would really like about images, is that they are unbounded,.
that is,. they are an infinite plane, that samples can be requested from
and placed into,. it would of course have bounding box etc,. and it
would need attributes about how the parameters are passed,.
Wrapping the pointer to the actual data in a special framebuffer node
makes sense to me,. at the moment I do not have the "drawable" filter
type,. but as I see it, it should be interchangeable with for instance
my video4linux filter,. avi_loader, png_loader,. or similar,. this is
the in memory buffer variation. It keeps the g*gl API cleaner.
Hopefully you find these ramblings useful.
--
.^.
/V\ Øyvind Kolås, Gjøvik University College, Norway
/(_)\ <oeyvindk@xxxxxx>,<pippin@xxxxxxxxxxxxxxxxxxxxx>
^ ^
