> > The producer and consumer interface would have GeglNode as a > prerequisite. An image producer is something that has images as output. > An image consumer is something that has images as input. This might > be better constructed as a GeglDataProducer and GeglDataConsumer > subclass. This would allow us to do things like check that the proper > consumer/producer is attached to an appropriate op of the opposite type. > Also the consumer/producer interface might provide methods to > interator of its list of inputs for the partiular relevant type. What I > really belive is that there is value to declaring that an object just > produces images (has outputs) just consumes images (has just inputs) or > does both. It also lets me make the GeglNode class look cleaner (I > think anyway). I agree with most of this and I see that ImageProducer and ImageConsumer might be useful as an interface in some situations, but I dont see concretely where it would help us. It may be I need to just think about it a little more is all. Also be careful, the outputs and inputs for ops dont have to be images. They can also be scalars, or strings, or whatever. We have a bunch of operators here, some of which have image inputs and outputs. Let me think about this for a bit. > > > > >>-GeglData- > >> (GeglChannel behaves like a continuous block (through a good *non > >> existant* api :-) It's backed by tiles.) > >> *GeglChannel* > >> *GeglScalar* > >> *GeglPixel* > >> -GeglDataContainer- > >> *GeglImage* (this is because Images can be > >> seen as a set of channels or set of pixels) > >> *GeglScalarArray* > >> *GeglPixelArray* > > > > > > This is based on the current GeglData hierarchy, correct? > > If so, this is sort of the right idea, at least for the Data hierarchy. > > Except I think you are confused what GeglChannelData is. The current > > GeglChannelData is similar to a scalar, except it is restricted to the > > channel data space. eg 0-255, 0.0-1.0, 0-65535, etc. If you are > > going to pass an array of these things you would probably pass > > that as a grayscale Image with that channel data type. > > Yes, this is based on the current GeglData hierarchy. Except I don't > like the GeglImage and GeglImageData distinction; mostly 'cause I don't > see why it must exist. I think you said that to read an image, you > subclass GeglImage, but shouldn't an image reading function be a node in > the execution graph? And if so, doesn't that mean that our real image > objects are the GeglImageData which are passed around by the nodes? So > I did away with GeglImage and dropped data out of the class name of all > the subclasses of GeglData (since they are data by being a subclass, so > I feel the longer name didn't contribute much to it's description). No. A FileIn node is a subclass of ImageOp, not Image. And yes, a FileIn node (or FileOut node) is part of the execution graph for sure, and they will have process methods like any other thing that inherits from Op. I think the difference between GeglImageData and GeglImage becomes a little more clear when you say that GeglImageData stands for a rect on an image (the result rect) that you want computed. If there were several threads computing different parts of an image, I think there will be several GeglImageData objects all pointing to the same underlying GeglImage, just each one is computing different parts based on their result rects. You could try to coelesce ImageData and Image, but you will have to find a new place for information like the result rects, and the synthesized color models that are computed during the pre-passes of the graph. I dont think you should keep that information in the GeglImage object directly. Calvin
