On Sun, Oct 19, 2008 at 6:16 PM, David Reaves <register@xxxxxxxxxxxxxx> 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.
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
