On Sat, Mar 08, 2003 at 02:41:34PM -0800, Daniel Rogers wrote: > Just a little update on what I am working on. > > So, I started with wanted to add a mask input to unary operations. I > thought that mask's should be optional inputs, so this led to a > discussion about how to change scanline_processor_process and the > operator processing functions so that GeglData is passed, instead of > pointers to images. Right. The mask is to be an optional image input to ImageOp. If that input is NULL, then it assumes the mask is 1.0 everywhere. I think once you have lists of GeglData passed to the subclasse's process and scanline functions you should be able to make some progress on the mask input. Also we are doing this so that operators can get all of their properties out of the data lists, rather than just retrieving them from a private field in the object. This is so that we can do things like convert the data to the appropriate type and also so that any of the properties of an op can be set from other input nodes. (Like time nodes, animated curves, etc) > At this point, I have an untested, but believed to be complete version > of scanline_processor_process that passes the GList of GeglData > pointers after properly initializing image iterators. What I need to > do now though is change every single operators' process functions. > This is a sucky about of highly repetative, yet straight-foward > changes that I have yet to tackle. Because of this huge change to so > many files, I started looking at what else may need to affect how > these functions are writtin, so we can minimize the number of times > all the functions are re-written. I recommend for the time being, just think about the floating point case, dont worry about abstractions like this just yet. I know there are a few 8bit and 16bit data types there, we should just keep them to a minimum until we are ready to go further. > The first thing I decided is to put in a slower, but simplier system > that would allow these functions to be rewrittin more quickly, yet > easilly replaced when the time comes to make decsions about > optimizations. This is to put an abstraction over pixels that allows > processing functions to get away with not knowing what datatype the > pixel is stored as. THis would allow floats to be a general > processing space, where the data is converted to floats, processed, > and converted back. I was concerned about the additional overhead of > this conversion, but you exsisting code already provided an answer to > this. > > First, suppose that we can provide an interface to pixel data such > that you can request and set the pixel data in whatever form you like, > but if the pixel data is already in your requested form, it returns > the pixel with nill overhead. > > Then you tell the operator what type your pixel data is in and the > operator returns the best function it has for processing that kind of > data. (this is nearly identical to what you already do now, except we > can provide a best, instead of exact fit). This would allow us, as > developers to focus on getting this working at first by only providing > the function that operates in the largest (most accurate) data type we > have available (float) and then later, after the code changes have > settled down (or perhaps only when necessary) we can write versions of > the processing functions specialized for data types. Like I said above, just concentrate on the float case for now for all the stuff you are thinking about. The kind of technology you are talking about will come later. > I really think I am on to a descent design for the tiling and caching > system. So here is my current todo list. I believe thinking about the tiling is fine, and I think you might want to do that separately from any caching. Just assume that all tiles fit in memory for the moment. There is quite a bit of work to do just to get Images that have multiple tiles, and Iterators that are tile-aware, aside from any caching issues. > Flesh out tiling, cacheing system api. I recommend Think about the tiling first, ignore caching for now. > > Write data-type independent accessor functions. Just do floating point cases for the most part. Dont worry about the data-type independent stuff right now. > Rewrite all the operators' process functions to take advantage of the > last two steps, as well as the changes to scanline_processor_process. Rewrite them to be passed the data lists like we discussed would be a good first step. > Write support for an optional mask input to Unary operators. You can do this after you have the data lists passed the scanline routines. Its independent of any tiling issues you mentioned above. > I do expect it will be a while before I start producing a working > system incorporating all these features. Dont try to work on everything at once. Just do things incrementally so we can re-factor it gradually and figure out if we are doing the right thing as we go. > If you want, I can send you the changes I have made so far to > scanline_processor_process (and a few other files). This code, > however breaks gegl. Email them to me and Ill have a look. > I am starting to work on the tiling and caching system right now, > outside of the gegl source tree (to flesh out ideas). When I get > something working in that area, I will let you know, and you can take > a look at that (if you want). > > I hope this is satisfactory (e.g. I am not stepping on stuff you are > working on) No, its fine. My next order of business is to straighten out how validate_inputs, validate_outputs work and how to make automatic conversions of inputs work during these routines. For example if you have an op that has two image inputs, one Gray and one RGB, you will have to have the Gray image "promoted" to RGB to make the op work. This has to happen in a place like validate_inputs method. Also if a particular input is NULL, like say a scalar input, then the op has to know to retrieve the value of that input from one of its private fields and provide that in the Data object that is in inputs data list. This is so the op can retrieve it during process. Those are the issues I am thinking about at the moment. Calvin
