Ramblings and Congrats
This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| Ramblings and Congrats | David Reaves | 19 Oct 19:16 |
| Ramblings and Congrats | Øyvind Kolås | 24 Oct 21:00 |
Ramblings and Congrats
First off I wanted to say that I have mixed feelings about this project because I was gearing up to try and start my own open source project to basically create a domain specific image processing language with dynamic processing etc... So I am sad that this one exists but also really happy because it appears to have a larger scope than my original project did.
I just wanted to ask some questions out of laziness, make some comments, and congratulate you.
I am going to ask this because I haven't dug through the code yet: I was wondering do you have the ability to reduce a series of arithmetic operations into the smallest necessary subset of operations required? (image+3 then image+4 should be image+7) This is one of the steps I know a compiler does but I wanted to find a open source library that accomplished just that feat. (I didn't want to have to rip it out of gcc in some ugly way.) Did you find such a thing? (I was worried about doing this for floating point operations where I know there are a considerable amount of idiosyncrasies that make it a hard problem.)
The other question I had (out of laziness of not wanting to do a lot of research) is: Why is there GeglOperationPointComposer in addition to GeglOperationComposer? Can't that information be determined at runtime? Without thinking about it too much, this seems to unnecessarily over-complicate your API.
Last lazy question: It there the capability to compile code from your "language". Or do you see the overhead of compiling as inconsequential compared to the gains of the more intelligent processing your algorithms? I ask this because my language supported convolutions and when you compiled my code I was going to put all of the convolution kernels into frequency space and pre-multiply the consecutive ones. Doing this would save a substantial amount of processing at runtime. (Especially if you simply want to apply the same set of operations to a large number of files.)
One thing I wanted to do for my project was to allow what I called "dynamic operations" which basically just meant that I would hand them some information and they could push more operations onto my operation stack at runtime. It was also going to be scoped so that if you asked for information from the whole image you would be able to edit the operation stack for all the pixels in the image but if you received information from a region or a single pixel then you would only be able to edit the stack for those pixels. I was worried that having a separate stack for each pixel might generate quite a bit of overhead so I was considering limiting it to only have whole image dynamic image operations but I still think it is a useful operation.
In that same vein I was wondering if it would be possible so generate image statistics as you were applying another operation to an image. Basically if I have operation X but if I apply a getImageStatistics operation right after it then it might be more efficient to obtain those statistics for each pixel immediately after the previous operation is applied, while the pixel value is still in the cache. (Sorry, that statement is confusing.)
If you really want this project to use efficiently use multiple machines you should look at ZPL. It looks like this project has stopped being developed but it might provide some insight to the challenges ahead: http://www.cs.washington.edu/research/zpl/home/index.html
By the way, congratulations! This looks like it is going to be an amazing project. I hope to help in some small capacity.
Ramblings and Congrats
On Sun, Oct 19, 2008 at 6:16 PM, David Reaves wrote:
I am going to ask this because I haven't dug through the code yet: I was wondering do you have the ability to reduce a series of arithmetic operations into the smallest necessary subset of operations required? (image+3 then image+4 should be image+7) This is one of the steps I know a compiler does but I wanted to find a open source library that accomplished just that feat. (I didn't want to have to rip it out of gcc in some ugly way.) Did you find such a thing? (I was worried about doing this for floating point operations where I know there are a considerable amount of idiosyncrasies that make it a hard problem.)
The only place something similar is done in GEGL is for consequetive affine transformations (the "translate", "rotate", "scale" ops) that they are collapsed to a single op (actually turning the other ops into no-ops that just pass buffer references along.) GEGL as currently implemented provides an API for chaining together more complex units or blocks of image processing than a single addition operation, though for many of the point operations some internal collapsing and recompilation using approaches similar to what is used by the mathmap gimp plug-in.
The other question I had (out of laziness of not wanting to do a lot of research) is: Why is there GeglOperationPointComposer in addition to GeglOperationComposer? Can't that information be determined at runtime? Without thinking about it too much, this seems to unnecessarily over-complicate your API.
All operations are added at compile time, these are the sources for the base classes used to implement composer operations. GeglOperationPointComposer contains a simpler interface to implement for implementors and machinery that allows low or zero traversal of the involved buffers. An op subclassing GeglOperationComposer would be operations that depends on data from varying or different locations within the buffer.
Last lazy question: It there the capability to compile code from your "language". Or do you see the overhead of compiling as inconsequential compared to the gains of the more intelligent processing your algorithms? I ask this because my language supported convolutions and when you compiled my code I was going to put all of the convolution kernels into frequency space and pre-multiply the consecutive ones. Doing this would save a substantial amount of processing at runtime. (Especially if you simply want to apply the same set of operations to a large number of files.)
One thing I wanted to do for my project was to allow what I called "dynamic operations" which basically just meant that I would hand them some information and they could push more operations onto my operation stack at runtime. It was also going to be scoped so that if you asked for information from the whole image you would be able to edit the operation stack for all the pixels in the image but if you received information from a region or a single pixel then you would only be able to edit the stack for those pixels. I was worried that having a separate stack for each pixel might generate quite a bit of overhead so I was considering limiting it to only have whole image dynamic image operations but I still think it is a useful operation.
Not quite sure I understand, architecturally the current GEGL core is heavily focused on caching results. This is done by having most nodes in the graph themselves contain buffers containing the results of earlier computations, this allows avoiding unneeded recomputations when the composition is altered.
By the way, congratulations! This looks like it is going to be an amazing project. I hope to help in some small capacity.
GEGL has been around for more than 8 years already, it was dormant for years but has already been fully capable of doing basic graph based processing and compositing for the last couple of years. Help is welcome, feel free to ask further questions about GEGLs current architecture when the code is cryptic (The first iteration of internal refactoring of internals after the public API had started to settle properly isn't fully done yet.)
/Øyvind K.
