I was talking to pipping tonight because I made a gegl op for outputting into a GdkPixbuf and wanted to import it into cvs.

Hi,
will it be possible to compile gegl in an independent way from any graphic lib?

./configure --without-gtk

Hi,

On Fri, 2006-08-04 at 21:22 -0500, Cody Russell wrote:

I was talking to pipping tonight because I made a gegl op for outputting into a GdkPixbuf and wanted to import it into cvs. He mentioned that we should import gegl-operations into its own module in cvs and it needs to be organized in a meaningful way, so I volunteered to post on the list and get some discussion on this going.

The module could be organized into different subdirectories: gegl-operations/
input/
output/
filters/

Does it really make sense to have a separate CVS module for this? After all the two modules will have to be in sync anyway so it would probably be easier to keep the operators in the gegl CVS module. We could still release two distinct tarballs from this source if that is desired.

Sven

On 8/8/06, Sven Neumann wrote:

Does it really make sense to have a separate CVS module for this? After all the two modules will have to be in sync anyway so it would probably be easier to keep the operators in the gegl CVS module. We could still release two distinct tarballs from this source if that is desired.

The core set of operations should live in the source of the GEGL library itself, these are operations that have no additional dependencies, and are considered necessary to make minimal use of GEGL (porter-duff compositing operators, math operators, gaussian blur).

The ones that have to be external to GEGL in my opinion is operations that have external dependencies (specialized file loaders), wrappings around other image processing libraries and other things that traditionally would be "filter plug-ins" in the legacy GIMP world.

/Øyvind K.

Hi,

On Tue, 2006-08-08 at 11:35 +0200, Øyvind Kolås wrote:

The core set of operations should live in the source of the GEGL library itself, these are operations that have no additional dependencies, and are considered necessary to make minimal use of GEGL (porter-duff compositing operators, math operators, gaussian blur).

The ones that have to be external to GEGL in my opinion is operations that have external dependencies (specialized file loaders), wrappings around other image processing libraries and other things that traditionally would be "filter plug-ins" in the legacy GIMP world.

I understand that and I didn't suggest to make them part of the core gegl library. I only suggested that they are kept in the gegl CVS module just like we keep a large set of GIMP plug-ins in the gimp CVS module. But I don't have a strong opinion on this, so if you think that a separate module makes sense, then go for it.

Sven

On 8/5/06, Cody Russell wrote:

Hi guys,

I was talking to pipping tonight because I made a gegl op for outputting into a GdkPixbuf and wanted to import it into cvs. He mentioned that we should import gegl-operations into its own module in cvs and it needs to be organized in a meaningful way, so I volunteered to post on the list and get some discussion on this going.

The module could be organized into different subdirectories: gegl-operations/
input/
output/
filters/

What currently is in the gegl-operations tarball is the following:

affine : affine operations (these should probably be moved into the core) file_io : jpg load, png load/save, dcraw wrapper, imagemagick wrapper (inputs or outputs)
generated : math ops and porter duff compositing operators (all composers, might be moved to the core, might eventually be implemented using GIL)
local : a place for "local" tests to be added, currently contains an invert op misc: text(cairo), threshold, contrast stretching, sdl display, gtk+ display, boxblur, perlin noise.

I think keeping file_io seperate from other things, might be a better mapping than
grouping them based on the superclass they derive from (input/output/filter/composer).

/Øyvind K.

On 8/8/06, Øyvind Kolås wrote:

I am currently experimenting with adding a lot of the operations to the GEGL module itself in the already existing operations directory, I've taken most of the structure for this sketch from the current menu structure of GIMP. A "D" indicates an op with external dependencies, the rest do not drag additional dependencies. Any comments?

/Øyvind K.

gegl/ operations/
artistic/
blur/
box-blur.c
gaussian-blur.c
color/
brightness-contrast.c
invert.c
stretch-contrast.c
threshold.c
core/
clone.c
crop.c
nop.c
shift.c
distort/
edge-detect/
file-io/
jpg-load.c D
load.c
magick-load.c
png-load.c D
png-save.c D
raw-load.c
generated/
math.rb
porter-duff.rb
generic/
map/
misc/
display.c D
noise/
render/
noise.c
perlin/
text.c D
transform/
affine.c
affine.h
chant.h
linear.c
linear.h
Makefile
matrix.c
matrix.h
module.c
module.h
nearest.c
nearest.h
rotate.c
scale.c
shear.c
translate.c
transparency/
opacity.c

On 8/9/06, Øyvind Kolås wrote:

On 8/8/06, Øyvind Kolås wrote:

I am currently experimenting with adding a lot of the operations to the GEGL module itself in the already existing operations directory,

I'm not confident that this is the correct approach long term, but it will at least be better than the current method of keepin a seperate tarball.

/Øyvind K.

Hi Pippin!

I am in a no-time-for-personal-projects rush now... :-(

But since you are at this of compositing modes, maybe you ? like to sniff my age old idea of programable blending modes.

It is stored as a GEGL feature request somewhere on bugzilla, along with code that used to work in an old gimp 1.3 that would take a stack of bytecode operators and with that make any custom 1:1 pixel blending in either RGB or HSV and there where even some provisions for CMYK

I think the idea of such a bytecode could be interesting. It can be too slow for some modes that cannot be cached for any usefull real time stuff - but maybe not.

When I get some time back I will try to dig further into that!

Regards,

JS ->

On Wednesday 09 August 2006 05:01 am, Øyvind Kolås wrote:

On 8/8/06, Øyvind Kolås wrote:

I am currently experimenting with adding a lot of the operations to the GEGL module itself in the already existing operations directory, I've taken most of the structure for this sketch from the current menu structure of GIMP. A "D" indicates an op with external dependencies, the rest do not drag additional dependencies. Any comments?

/Øyvind K.

gegl/ operations/
artistic/
blur/
box-blur.c
gaussian-blur.c
color/
brightness-contrast.c
invert.c
stretch-contrast.c
threshold.c
core/
clone.c
crop.c
nop.c
shift.c
distort/
edge-detect/
file-io/
jpg-load.c D
load.c
magick-load.c
png-load.c D
png-save.c D
raw-load.c
generated/
math.rb
porter-duff.rb
generic/
map/
misc/
display.c D
noise/
render/
noise.c
perlin/
text.c D
transform/
affine.c
affine.h
chant.h
linear.c
linear.h
Makefile
matrix.c
matrix.h
module.c
module.h
nearest.c
nearest.h
rotate.c
scale.c
shear.c
translate.c
transparency/
opacity.c

On 8/12/06, Joao S. O. Bueno Calligaris wrote:

Hi Pippin!

stack of bytecode operators and with that make any custom 1:1 pixel blending in either RGB or HSV and there where even some provisions for CMYK

I see no reason to restrict such an approach to point operations, any form of operations should be expressible in this manner. One approach would be something similar to the lua plug-in I wrote for GIMP [1]. Another, probably better approach, would be to resurrect GIL and allow it to be used on the fly.

I'm not sure such an operation has real merit though, most probably I'd be very cautious of incorporating it into the base set of operations unless it was part of an effort to resurrect GIL for precompiled, and JIT'ed point and area operations.

/Øyvind K.

1: http://pippin.gimp.org/plug-ins/gluas/