Hi,

Eric Grivel writes:

I went to gegl.org, downloaded the code (got it to compile), looked at the FAQ and the archive for this month of the mailing list... and found that I have no clue about what is going on and whether or how I would be able to contribute.

So my questions: - Is gegl the right place to contribute to a 16-bit version of Gimp?

Yes.

- Is this mailing list the right place to talk about gegl?

Yes.

- Is development going on that I could participate in?

Development happens in irregular intervals whenever someone finds the time and motivation for it. Last summer an effort was made to clean up the source code and to identify missing pieces. Pippin has since then developed babl, a library for color conversion that is waiting to be used from gegl. The most important missing piece at the moment is the code to actually store the image data. As soon as we have that, gegl would for the first time become actually useful and we can consider to start using it from GIMP.

Sven

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 ;-)

Von: Florent Monnier

So the first contribution are most often send as patch (man diff, man patch).

... and are preferably attached to a report in Bugzilla.

"send" implies email, and this would be a good way to have your contributions lost in a crowded mailbox.

HTH, Michael