On 23/09/04, Øyvind Kolås wrote: > * Calvin Williamson <calvinw@xxxxxxxxxxxxxx> [040923 18:02]: > > Anyway I think we commit to stick to double or float > > as the default, and decide which other types to support as well, > > It makes sense to enforce this for most filters, but some source > operations (mpeg4, png, v4l, svg (at least my cairo based thing)) > it doesn't make sense, the plug-in system should allow for developers > to just code for the pixelrepresentations they need, ignore the rest, > and be able to expect things to just work. Correct. The op is coded for whatever and the framework just figures out how to make it work. This means that there is a way to get to/from any given format/color model to the standard one (the connection space, in color management speak, presumably a double or float format). Every format/color model must describe how to get to the connection space then (like in an ICC color profile eg). > In gggl I do pixel representation negotiation in a seperate pass before > processing starts (this could be added as an additional pass in GEGL as > well I guess), this pass does negotiation on every connection in the > graph trying to find the best suited common format between the > operations, if no suitable pixel representation is found a proxy > operation is inserted proxy is my pixel representation "babelfish" We certainly need this mechanism in gegl as well, and some version of the proxy conversion ops too. > http://pippin.gimp.org/gggl/snapshot/ops/filters/pixfmt_conversions.h.html > http://pippin.gimp.org/gggl/snapshot/ops/filters/precalc_order.txt.html > http://pippin.gimp.org/gggl/snapshot/ops/filters/proxy.c.html > > and try to make it as easy as possible to add new types, but without > > burdening it all with a code-generating tool right now. > > Code generation is generally a good idea,. but a single standard is not > a good idea IMO. For instance the porter-duff operators have a very > similar structure, not using code generation / #include tricks or > something similar the amount of code gets quite large, fast. > > http://pippin.gimp.org/gggl/snapshot/ops/composers/porter_duff/generate.rb.html > > is the ruby based code generator I use in gggl to generate them all > (I should probably look into extending the porter duff code to be both > 8bit, 16bit and float since it is a case where a little work on the code > generator will provide a lot of functionality.) This kind of stuff is fine, it's just generating different data types coding that gets really difficult it seems. > > Defining a scripting language as a prerequisite for generating the GEGL > source (perhaps not true for tarballs?). I think we probably do want this, so that tricks like what you are doing for porter-duff are encouraged to be done in the same kind of way. Calvin
