Calvin Williamson wrote:
All good. Just one comment. Dont you want to do
a GeglBufferFloat, not double? I see that we will pass individual
colors, opacities, and other scalar parameters as doubles (gimp does
this already), but I dont think we need image data using doubles for now,
at least. Gimp will likely use an 8bit, some kind of 16bit format (I would
do some kind of a half-float), and float image in the foreseeable
future.
Well, the idea is that buffers are trivial to add. And yes, I imagine
the Gimp will use floats instead of doubles, but I think that the api's
should accept doubles, since there is no real reason not to. (Double
math is as fast as float math on most (all?) major platforms (SPARC,
x86, ppc)). GeglBufferDouble is the easiest to write, because of this.
(gegl buffer float is exactly the same, except with a typecast before
storing the elements).
On 18/08/03, Daniel Rogers wrote:
this is all good news. I yesterday was the first day since I got back
wednesday that I had any time to work on gegl. I have some GeglBuffer
and GeglBufferDouble stuff written, and I will try to get that into
place soon. I assume you want me to check in _working_ versions of this
stuff only?
Correct.
You could check in new stuff that is due to replace what is there now, and
write unit tests that would excercise it, but just dont actually hook up
the new stuff to the current front end.
gurr. Now I have to move stuff around.
This would require some different names till you switch over to new stuff.
Thats all fine, just as long as whatever unit tests are there pass.
I think I would rather have this stuff in a different folder, which a
different unit test application. Renaming stuff in a PITA when using
gobject.
Here is my plan of attack:
Write GeglBuffer (abstract) and GeglBufferDouble (concrete).
Write SampleModel (abstact), ComponentSampleModel (abstract) and
PixelInterleavedSampleModel (concrete).
Write ColorModel (abstract), ComponentColorModel(concrete)
Write GeglTile (the jai analog of this is Raster) using the above three
classes.
Write GeglImage as a collection of GeglTiles
Great. Oh yeah. Dont create any directories till you ping the
gegl-developer list with proposed name changes. Its really hard
to remove directories in cvs so we want to get the names right
first time.
ok. Consider this my ping. So, the fundamental image stuff (e.g. the
classes unrelated to ops) I would like to put in the directory
gegl/gegl/image. This would include all classes related to images (in
particular the stuff I mentioned I am working on). This would also mean
that we don't need to rename stuff if we use a different unit test app
that links only against libimage.a, at least until all this stuff is
integrated.
I might be tempted to suggest names for other subunits within gegl.
Those that come to mind are: geg/gegl/graph (all generic graph and graph
tranversal stuff), gegl/gegl/op (the operators and possible a future op
registry system).
--
Dan
