Jean-Sebastien Senecal wrote:

Hi,

I'm working on an open-source software for real-time mix-medias, similar to Puredata. We've started using part of the Gimp code for image processing. For now, I was able to move the composition functions in paint-funcs. However, since the functions are not documented, I find it often difficult to know what this or this is doing. Plus, I don't understand well how the files are organized.

Right now, I'm trying to find the part of Gimp's code that deals with layer placement and alpha composition. Could someone on this list tell me what functions to look for and how is the code organized in Gimp?

Thanks,

Jean-Sebastien

hi,

you could try asking on the linux-audio-devel list, they would be very interested in mixed media and image processing, especially image to sound processing.

best

mC~

Hi,

Jean-Sebastien Senecal writes:

I'm working on an open-source software for real-time mix-medias, similar to Puredata. We've started using part of the Gimp code for image processing. For now, I was able to move the composition functions in paint-funcs. However, since the functions are not documented, I find it often difficult to know what this or this is doing. Plus, I don't understand well how the files are organized.

You are trying to reuse the part of the GIMP code that we would like to get rid of the sooner the better. The basic image manipulation routines date back to the early days of GIMP development and haven't seen the refactoring that all other parts of the code have gone through. I would not suggest to use this code at all. You should consider to use GEGL instead. But then, GEGL is probably not at the point yet where it would fulfill your needs.

Sven

On Sun, 24 Oct 2004 14:13:54 +0200, Sven Neumann wrote:

Hi,

Jean-Sebastien Senecal writes:

I'm working on an open-source software for real-time mix-medias, similar to Puredata. We've started using part of the Gimp code for image processing. For now, I was able to move the composition functions in paint-funcs. However, since the functions are not documented, I find it often difficult to know what this or this is doing. Plus, I don't understand well how the files are organized.

You are trying to reuse the part of the GIMP code that we would like to get rid of the sooner the better. The basic image manipulation routines date back to the early days of GIMP development and haven't seen the refactoring that all other parts of the code have gone through. I would not suggest to use this code at all. You should consider to use GEGL instead. But then, GEGL is probably not at the point yet where it would fulfill your needs.

gggl ( http://pippin.gimp.org/gggl/ ) might be a starting point, since gggl aims to
be API compatible with a future GEGL. If you are going to use such functionality from a higher level programming language a future migration should be easy.

At the moment I've been mainly focusing on high quality, rather than high speed and thus implemented most of the image processing only for floating point buffers.
The system is designed to allow for optimizations in the form of adding 8bit/16bit versions of operations alongside the floating point versions.

My intention is to port my abstractions on top of gggl to GEGL, and thus my tool chain from gggl to GEGL, after that porting the operations is one of my priorities.

Depending on how urgent your needs are,. if you have some time to spend helping out with GEGL development in the near future, that would also be greatly appreciated.

-- Web : http://pippin.gimp.org/ .--------------------------------- Mobile : (+47) 97 62 81 98 | Software patents hinder progress Office : (+47) 61 13 52 07 | http://swpat.ffii.org/

On Tue, 26 Oct 2004 22:18:08 -0400, Jean-Sebastien Senecal wrote:

Øyvind Kolås wrote:

On Sun, 24 Oct 2004 14:13:54 +0200, Sven Neumann wrote:

Hi,

Jean-Sebastien Senecal writes:

I'm working on an open-source software for real-time mix-medias, similar to Puredata. We've started using part of the Gimp code for image processing. For now, I was able to move the composition functions in paint-funcs. However, since the functions are not documented, I find it often difficult to know what this or this is doing. Plus, I don't understand well how the files are organized.

You are trying to reuse the part of the GIMP code that we would like to get rid of the sooner the better. The basic image manipulation routines date back to the early days of GIMP development and haven't seen the refactoring that all other parts of the code have gone through. I would not suggest to use this code at all. You should consider to use GEGL instead. But then, GEGL is probably not at the point yet where it would fulfill your needs.

gggl ( http://pippin.gimp.org/gggl/ ) might be a starting point, since gggl aims to
be API compatible with a future GEGL. If you are going to use such functionality from a higher level programming language a future migration should be easy.

At the moment I've been mainly focusing on high quality, rather than high speed and thus implemented most of the image processing only for floating point buffers.
The system is designed to allow for optimizations in the form of adding 8bit/16bit versions of operations alongside the floating point versions.

My intention is to port my abstractions on top of gggl to GEGL, and thus my tool chain from gggl to GEGL, after that porting the operations is one of my priorities.

Depending on how urgent your needs are,. if you have some time to spend helping out with GEGL development in the near future, that would also be greatly appreciated.

Actually, part of the software we are currently developping is pretty similar to gggl. However, what we fear is that : 1) gggl as well as GEGL are not implemented with real-time processing in mind

I have been successfully using gggl in interactive displays, at the moment I focus more strongly on being correct than being fast, adding 8bit support; in addition to floating point, to the needed/most used operations is all that would be needed for software optimizing. It might also be feasible to hardware accelerate some operations.

2) none of them tries to integrate audio

Work has started on integrating audio in gggl, my initial approach works for non real time rendering,. (dropping video frames is acceptable, dropping audio fragments is not). Thus audio and video needs to be separated, the simplest robust way to implement synchronized playback is to have audio and video in separate threads syncing the video thread to the audio time.

Having them in separate threads would be easiest by splitting audio/video handling.

What we're really looking for, and would like to contribute to in the

near future if such a project takes place, would be a library that generalizes the concept of graphical flow to both audio and video (and, maybe, other inputs like signals from sensors or even chains of words) and that tries to integrate very efficient processing algorithms for at least the basic effects (like image compositions). I haven't heard of such a project for now.

Another project you maybe haven't heard about that can be interesting to look at is:

http://mlt.sourceforge.net/

Although the intentions of those projects somewhat differ from the things you plan to do.

/pippin | Øyvind Kolås