Re: 16bit channels, doh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/1/05, michael chang <thenewme91@xxxxxxxxx> wrote:
> On 10/31/05, Brannon King <brannonking@xxxxxxxxx> wrote:
> > So I was told to see the GEGL info.
> >
> > That website (gegl.org) drastically needs a FAQ.
> > Perhaps someone can answer these questions for me:

http://www.gegl.org/new/ was the state of the new GEGL web page a
couple of years ago when GEGL had some momentum. I spent a large
portion of this summer familiarizing myself with the GEGL code base
with the intention to pick up the work again, but progress is a bit
slow since I have quite a few other obligations as well. Gggl[1] is my
prototype of a GEGL like library (the download able software is out of
sync with my local tree at the moment and is unlikely to change in the
immediate feature (before Christmas).

My GEGL focused energies were redirected to a helper library to do
pixel representation conversions this summer, and I am trying to find
the odd hour or two I can spare the project each month, babl[2] is
currently in a usable state and needs some minor cleanups before an
API frozen 1.0 release can be made.

> > 1. Is GEGL made to replace a certain core piece of
> > GIMP or is it made to reroute data somehow?

GEGL is intended to replace at least the compositing in the layers
stack, but since it is a general graph based compositing architecture
it is likely that all image processing functionality of the GIMP
should be migrated to GEGL-nodes (including filters and tools).

> > 2. Why is it not part of the GIMP core currently?

Because GEGL isn't able to process image data yet, thus The GIMP would
be unusable if it should depend on GEGL in its current state.

> > 3. Is it activelly being worked on? Is its mailing
> > list still used?

http://cvs.gnome.org/viewcvs/*checkout*/gegl/ChangeLog
http://cvs.gnome.org/viewcvs/*checkout*/babl/ChangeLog

> > 4. It appears to just be an API. Why would using this
> > be better than changing the current GIMP core to
> > support 16bit channels directly? Or are we planning to
> > do just that and just use the GEGL API data structures
> > and constructs?

Cinepaint which used to be called FilmGimp which forked off the Gimp
is going down this route.

> > 5. How close is the GEGL code to usable?

Hard to say since there has been a discontinuity in the development
(take a look at the ChangeLog and see which people have been active at
what time.)

> > 6. Will it even work with the current GIMP codebase?
> > 7. Has anyone worked on a merge plan for combining
> > GEGL work with the current GIMP codebase?

Much of the GIMP development over the last few years have been about
modularizing and gobjectifying the code this has lead to a separation
that will make a merge with GEGL easier in the future. At the moment I
think the GIMP code base is in a phase where gradual replacement of
the code with GEGL based bits could happen if GEGL was ready, but GEGL
isn't ready.

/Øyvind K.

1 : http://pippin.gimp.org/gggl/
2 : http://pippin.gimp.org/babl/
--
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux