On 19/01/04, Daniel Rogers wrote:
>
> again, at gimpcon, we agreed. Images are the _only_ kind of data we
> should be worried about. GStreamer already handles sound, scalar, and
> geometry data. Even animation data is not something that needs to be
> handled at the "graph" level. It can be handled at a higher level, even
> outside of gegl.
Im not trying to say that we are or should be a system
that tries to do everything. I was just explaining that
because of the way the system works now, you can
pass any kind of gobject property data with a simple
dfs pull mechanism.
I apologize, I think I over illustrated this to the point of
making you think I now want to pass everything under
the sun, but thats not my primary interest. Its just
true that you can pass anything, once you
say you will use g_object_gets and g_object_sets
to pull and pass any kind of input and output data.
I believe the fact that it is possible gives us a
chance to think about using this approach
to port gimp to gegl in a gradual manner at first
using gimps existing tile managers and buffers as the
underlying image data, and the already
existing gimp image processing code. And using none of
GeglImage, GeglColorSpace, GeglColorModel, GeglDataBuffer, or
GeglTile, at first. Just wrapping tilemanager
pointers and passing them along using the glib properties
pulling. You could wrap gimp tilemanagers and tempbufs in
a simple standin GeglImage though too, if you
want.
I think this is a pretty reasonable approach to
suggest and I for one would like to spend some
time thinking about it, looking at the gimp
source code, and even doing some test ports
of say the projection code and the paint hit
code.
The idea that we will get the right set of ops in
gegl at first with all the parameters in all the
right places and using completely new image buffers at
the same time is hard for me to see. Maybe it could happen,
but its just hard for me to see it right now.
>
> I don't what we gain, except overlap with other projects and undue
> complexity by over-generalizing the graph. Gegl should only be an image
> processing library. When we want to handle sound and image we can write
> adaptor classes for gstreamer.
> That given, there is no reason to mix up the connections with the other,
> arbitrary properties. For one thing, there will be properties that we
> don't want to be able to connect to one another, so keeping the pads
> seperate from the properties seems like a good idea. Futher, there is
> no need for all the property machinery for representing node
> connections. Finallay, I don't believe that the property model fits
> will the the graph connection model. There is a lot more than simply
> the existtance of a point of connection (like how many connections, how
> many connected, ROI's, DOD's, the GeglImage that is shared between the
> endpoints, etc).
I think there are some good reasons for the "property machinery",
and localizing traversal code on properties even if you are thinking
only of image data.
Introducing a property or pad object that holds the connection across
from inputs to outputs solves at least a couple of tricky little graph
manipulation issues:
1) Issues with temporary ops and inserting these into the graph at
a convenient spot. One place where this tends to come up is where
you are passing images along and need to convert data types or
color models in order to continue to the next step.
2) Issues with container nodes (ie Graphs), The
various children want to have their properties directly
connected to each other, while the node connections want to
stay at the level of graphs. Here is an example where the
innermost op on the left may be connected to the innermost
op on the right, and that is a property connection of
some kind. But the node connection sort of wants to stay
at the level of the outermost container graphs on each side.
----------- ----------
| |
+| |-
| | |-------
|------ | | |-
| +| | |- |
| | | | |
| | | | ------
| +| | |----------
|----- +|
|
-----------
Now one solution is to "flatten" the graph before you
do any kind of traversal, but then you have to go and
unflatten after a traversal.
By using a property object that holds the connection, you
let the properties stay directly connected and the node
connection stay at the level it wants to at all times
too.
I have seen this idea in gstreamer in the form of
ghostpads, and it is in maya in the form of what
it calls plugs.
3) Its a convenient place to put inherited and
synthesized attributes that are passing along a property
line, possibly rects of some kind going up and down
the graph during a set up, or color models being
determined from the leaves of the graph back
up to the root.
And yet another purely practical reason for the property stuff
Its just easier to debug graph and container and traversal
code if you just can set up some simple scalar ops and
write some unit tests using these. Traversal and graph
negotiation coding is pretty much the same no matter
what properties/nodes are there. So I just started
registering regular old gobject properties as connections
too so I could test this way along with working on the
other problems above.
Anyway all of this property machinery is not just
abstract generalization for no particular reason.
>
> >So we have an evaluation manager set up everything after a call to
> >the root property, it does preliminary propagation of inherited
> >and synthesized attributes down and up the graph and queues up
> >whatever multi-threading tasks there will be, and
> >descriptions of those tasks. Of course these tasks are
> >arranged so that they are done in a way consistent with the dependency
> >graph, but that is really the only restriction.
> >
> >I think that leaves a lot of freedom to decide how to break up your
> >evaluation and calls on the nodes and properties for them to
> >do their thing.
>
> All you have is a name and you say "the evaluation manager leaves us a
> lot of freedom." I just wrote a long email explaining precisely why I
> think things should be done a particular way, given design constraints.
> Did you have any coment on that?
As far as I understand it all those issues have to do mostly
with a particular type of evaluation manager, one that assumes it
is only dealing with and queuing up gegl image data for image-only
tasks and passing them back to gegl image ops.
I apologize if I am not understanding you correctly... I think I
might be able to respond better if you would go ahead and check
in some proposed GeglImage header files or write up some gtk-docs
on your approach.
>
> If we are not subclassing GeglImageOp what is the point? If you want to
> do image processing outside of gegl, don't use gegl? Why should be be
> accomdating different kinds of image processing library that will likely
> want to do things completely differently anyway. I don't see how you
> could get that "graph processing mileage" without all the machinery of
> it. The machinery _is_ the graph processing mileage.
Im just saying the initial set of gimp image ops might use tile managers
and tempbufs and all of the existing gimp compositing code underneath
as described previously. And then in the future they might switch over
and become image ops that use gegl tiles, gegl buffers, gegl color models
etc and gegl compositing code. I am thinking about that approach.
>
> >Im just trying to emphasize that the property, node
> >and data passing framework should be kept minimal and general
> >at the highest level. I think that you can arrange the image
> >passing subsystem of ops in most anyway you want really
> >within this framework.
>
> But you are doing exactly the oppositing. Your data passing framwork
> can't be minimal, it is trying to do so much, and I don't see why we
> need that much generality. It just makes things so complicated. (and I
> mean complicated to implement).
>
But the framework that passes glib properties is very minimal and is
in cvs now. You can have a look at the unit tests to see it in
action. At least at the level we where we could use it to help
port gimp and create gimp image ops.
Calvin
