> As I mentioned before, I have quite a lot of experience in C programming > (and other languages, for that matter), but zero in open source > development and/or graphics. I think I might be able to make a > contribution, but need someone to help me get started. Open source projects are most the time coordinated through CVS (or CVS like systems). But before to get a CVS access the maintainers of it prefer to see the quatlity of the contributions made by someone to prevent the CVS tree database to be corrupted, like a Wiki can be when everyone can write in it. So the first contribution are most often send as patch (man diff, man patch). Make your patch with the command 'diff -U 5 src.c.orig src.c' on the very last version of the file which you just got through cvs. I am not experienced in C programming at all, just a c beginner as a hobby :), I'm infographist and i've learn to program to be able to get in the sources of the tools I use because there are often ergonomics choices I would like to change. If you want to introduce smoothly yourself to graphics programming there is a very good tutorial made by Pippin: http://pippin.gimp.org/image_processing/ Perhaps you're too experienced for this introduction, but for me it was just perfect! You could also have a look at IM and GM, to see how they store and process image data. http://www.graphicsmagick.org/ http://www.imagemagick.org/ It is possible to choose the number of bits used for pixel values before compiling with ./configure --with-quantum-depth 16. The default is 8 bits for GM and 16 bits for IM. The default range of IM is 0 < 65535, in Gimp it seems to be 0 < 255 I think. But to use IM on a web-server perhaps it is a beter idea to compile it in depth 8, I'm not sure. IM is integrated with PHP trough php_imagick, and on Debian it seems that the default quantum 16 has been keept. As you said you "was looking for a way to contribute to the development of a 16-bit version of that tool", maybe the IM technical choices to switch on this could interest you. But before to make an equivalent implementation for Gegl, perhaps you should ask to the Gegl leader which implementation should be choosen. I don't remember if there are things around 8/16 bits in pippin's gggl. > Is there some interface defined that needs implementing? Is this about > saving an image to a file, or the internal in-memory storing? What are > the relevant data structures? Or, in other words, where to start? Here the Gegl gurus would be more appropriate to answer ;-) -- Best Regards _______________________________________________ Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
