On Fri, Apr 04, 2003 at 02:54:11PM -0800, Daniel Rogers wrote: > Do you have a more "presence oriented," transient form of communication > I could use to get ahold of you (like an IRC channel where you hang, or > AIM or ICQ etc)? > I have zero bandwidth for the next few days unfortunately but will have more after I get a couple of things out of the way. We should have Sven set up a #gegl for us and try to use it regularly. > It is unclear to me why we want to generalize the graph so that we can > pass non-image data types. It seems like a tremendous amount of > increased complexity for little potential benefit to an image processing > library. > I do see that it has numerous theoretical advantages. Obviously being > able to treat images just like anything else is pretty spiffy. However > I am finding it difficult to come up with many situation where you want > to pass non-image data in the same way you pass image data along the > processing graph. Let me try to explain what I mean: One good example is if you have an Op with inputs that are animated parameters. This is the main case I can think of that would be useful actually. For example you might have a animated spline curve or some animated scalar parameter (like frame number or time) that you want to pass to an Op. One way to do this is to attach as input an op that outputs your animated param. This is pretty standard technique for things like scenegraphs or hypergraphs (like maya) to get animation engines into the graph, and that is why it would be good to make it work for gegl too. Though it is extra work, I think you have to be able to pass other data along the graph to cover these kinds of animated param nodes. Calvin
