Hi,

Colin Bennett writes:

I'm a Linux hacker and GIMP user and am interested in helping out on GEGL. I had two main questions:

1. What is it really going to take to integrate GEGL into the GIMP? Is it something that might happen this year? Next year? GIMP 2.2? What are the steps it's going to take to integrate?

GIMP is less than two weeks before the feature freeze for 2.2 so GEGL is definitely not going to make it into GIMP 2.2. The reason for pushing the 2.2 release is however to make it possible that we finally start to work towards GEGL integration.

2. Where can I help out on GEGL? I've done quite a bit of graphics programming in Java (recently) and C/C++/assembly (back in the Good Old DOS days). I have lots of experience with unit tests and mock objects (the company I worked at for several year specialized in Extreme Programming).

I checked out CVS and was very glad to see that everything built smoothly and the tests ran perfectly. I'll be browsing the code and the docs a little but it I can have some idea of what kinds of tasks I could help with, I'd have a place to focus on in greater depth.

I'll leave that question to the GEGL developers...

Sven

Colin Bennett wrote:

Hello,

I'm a Linux hacker and GIMP user and am interested in helping out on GEGL. I had two main questions:

1. What is it really going to take to integrate GEGL into the GIMP? Is it something that might happen this year? Next year? GIMP 2.2? What are the steps it's going to take to integrate?

I've outlined this elsewhere. I'll attach my notes at the bottom.

I really, really want 16+ bit color and adjustment layers. Sometimes I almost feel like wiping out Linux and installing WinXP and Photoshop... :-(

2. Where can I help out on GEGL? I've done quite a bit of graphics programming in Java (recently) and C/C++/assembly (back in the Good Old DOS days). I have lots of experience with unit tests and mock objects (the company I worked at for several year specialized in Extreme Programming).

Ok . .. Great! Have you done JAI programming. I am taking some inspiration from that particular library. The current things I need help with are building a colorspace conversion interface (this will require lcms), a tile interator, and a multi-tile gegl image class. I could also use more extensive tests of gegl-buffer with using an on disk cache system. I have an implementation of GeglTile, which I can give you diff if you are interested. I kinda got real busy with life and took a break, but just last week started putting time into gegl agagin. Your timing is imppecable

I checked out CVS and was very glad to see that everything built smoothly and the tests ran perfectly. I'll be browsing the code and the docs a little but it I can have some idea of what kinds of tasks I could help with, I'd have a place to focus on in greater depth.

Currently there are the beginings of a generic image data access library in gegl/gegl/image. In gegl/gegl is the remenents of the old data access library and the tree construction code, which afaik works, but is not connected to the generic image data access stuff. I know exactly what needs to be done to finish the gegl iamge library, the big blocker being that I haven't had time to put into it until very recently. The most effective you could be would be to start with (one of) tile-iterator, color-model, and color-space. I can give you a diff against head which will have headers for those classes but be lacking in implementation. I also have oodles of notes on how I thought it should be done, but feel free to think of a better way. I am more than happy to do anything I can to help you along.

Here is what I outlined a few months ago on what needs to be done:

1. Finish gegl/image () Goal: gegl/image is the directory that holds the data access libraries. It should contain the abstractions for high-bit-depth and multiple color space manipulations. -- a. finish up my nearly completed tile caching code -- b. implement color space classes -- c. write gegl-image and gegl-color

2. clean up nodes () Goal: This will bring gegl all together. Modify the existing node system to handle the new image data types, and get a strong core of basic image processing nodes. Also, build a few image i/o nodes and actually build one or two gegl test programs that actually manipulate image data. One might argue that this step would "finish" gegl. -- a. make nodes work with the new gegl-image stuff -- b. design processing model that can handle multiple data types and sample models
-- c. implement the base set of core filters -- d. implement different bit depth processing functions (prioritizing by what the gimp needs) -- e. make gegl work

3. begin gimp integration () Goal: This puts abstraction in place to actually start handling image high bit depth and color management. -- a. replace tile manager with data compatible GeglBufferedImage. This involves modifying the existing gimp-compositing system to use GeglImage, as well as modifying GimpImage and GimpColor to use GeglImage and GeglColor.

4. start adding deep paint () Goal: to start allowing The GIMP to handle high bit depths. The initial integration should not take long, but I foresee unforeseen problems, so I am setting this estimate high. -- a. modify GimpImage and GimpLayer to use a set of GeglOps. -- b. design a new file format (this has already begun). -- d. convert the core (including paint) to high-bit depth. -- e. convert the plugins to high-bit depth

5. The big ones () Goal: start adding some long wanted features. a and b probably need to take place at the same time. -- a. build the CMYK painting system. This will involve figuring out all the equivalent CMYK and RGB operations, and modifying the GIMP to use CYMK equivalent operations in place of RGB operations. -- b. add color management to the gui. -- c. add layer effects
-- d. add layer groups.
-- e. add clone layers.

* Colin Bennett [040903 21:44]:

... I've spent some time since I first started looking at GEGL trying to understand the GObject system, since I've never used it before, and have come to the sad conclusion that it is N.A.S.T.Y.

I reached the same conclusion, which was also what lead me to implementing a gegl like library in plain c, the number of entry points I've ended up with into that library is very small, there are still loose ends, and things not implemented since my original goal was to do a global %s/gggl/gegl/ on all my source files.

A lot of work has gone into GEGL, and the code base has features not present in gggl. But gggl has one main feature which is the feature I demand when developing, it actually does something.

It has been briefly been discussed whether GGGL could be used instead of GEGL for gimp integration, the system that GGGL is a part of is already experimenting with effect layers, layers groups, clone layers and other benefits that GEGL will bring gimp, the file format used by the library above GEGL is also the xml based catalog format I am proposing for a future gimp file format.

http://freedesktop.org/~pippin/aluminium/

What benefits would we gain from using gobject within GEGL? Given that the api needed to interact with GEGL is very small.

ref.

http://freedesktop.org/~pippin/aluminium/aluminium-0.0.150/gggl/gggl.h

An intial plan was to start porting my hosting application gradually to GEGL by changing the core image buffer representation in GGGL with the new cache system Daniel has been implementing.

/pippin

Colin Bennett wrote:

Quoting Daniel Rogers :

Ok . .. Great! Have you done JAI programming. I am taking some inspiration from that particular library.

I've read about JAI and considered using it on a project but ended up deciding against it because of the non-open nature of the license and because it was a bit overkill for the small tasks we needed it for. So I have a little understanding of JAI's way of doing things.

... I've spent some time since I first started looking at GEGL trying to understand the GObject system, since I've never used it before, and have come to the sad conclusion that it is N.A.S.T.Y.

I also don't like the gobject system. I despise it really.

go figure. There are other people who are more interested in the language bindings, etc, but, I have dreamed of moving away from GObject for a while (or at least the C incarnation of it), for a while. There are aparently other people who strongly feel that gegl should be plain C w/GObject, and I've not had the will to argue with them. I've considered the possibility of moving to C++, D, python+C code, java + C code, and even sat down and tried to write out a D port, but gave up, because I didn't want to abandon this project, and it seemed like so much work. However, true mutidimenstional arrays, garbage collection, versioning, macros, paramaterized types, first class array objects, and inline assembly struck me as a beautiful language to build an image processing system in.

Anyway, if it would attract more developers than it would reject, I would be more than happy to consider a move away from the horrid mutant, psycho space monkey that is gobject.

-- Dan

P.S. It seems silly that one of the biggest attractions of GObject is that you can make all kinds of fancy language bindings for it, yet there are still only a handful and think of this: one of the goals of GObject is to be able to write language bindings so that one does not need to use GObject. . .

On Fri, Sep 03, 2004 at 02:00:12PM -0700, Daniel Rogers wrote:

P.S. It seems silly that one of the biggest attractions of GObject is that you can make all kinds of fancy language bindings for it, yet there are still only a handful and think of this: one of the goals of GObject is to be able to write language bindings so that one does not need to use GObject. . .

Exactly. The idea is that you give the freedom to the application programmer to choose the language that they want, and let them working with the library in the language's native way of doing things.

Yes, GObject is horribly lowlevel. C is horribly lowlevel. It's far far nicely to make GTK+ application in say, Python, than it is in C.

But GEGL is aimed at being *infastructure*, not an application. Part of being an infastructure developer is sharing your ball with people. Sharing is hard work sometimes, but hey, it means more potential users of your library.

GObject has bindings for C++, Perl, Python, Java, Ruby, C#, and a bunch of others I don't recall at the moment. So that covers pretty much all the major languages these days. One could call it a "handful", but it's a pretty big hand.

And it still gives the freedom for the poor, beat up C programmer who actually *wants* to use C.

C++, Java, etc. are hard to interoperate with. Not due to problems inherent in the language, but problems in the common implementations. C++ ABI isn't constant on all platforms, Java on many platforms means a huge, inefficient, and shoddily written JVM...

If the big issue is the mass of boilerplate code needed to make objects, there's basic stuff like G_DEFINE_TYPE, or generic code generators like gob, or domain specific generators like GEGL's opgen...

-Manish

Hi,

Manish Singh writes:

If the big issue is the mass of boilerplate code needed to make objects, there's basic stuff like G_DEFINE_TYPE, or generic code generators like gob, or domain specific generators like GEGL's opgen...

GEGL could indeed make good use of the new G_DEFINE_TYPE macros. I hope that as soon as we get GIMP 2.2 out of the door, we can give the GEGL code a thorough review and cleanup. I am for one really looking forward to hack on this codebase. Perhaps it's because I like GObject a lot and I think it's a good choice here.

Sven