RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

GSoC suggested project: OpenGL GPU resampling in GEGL

This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

7 of 7 messages available
Toggle history

Please log in to manage your subscriptions.
GEGL 0.0.22 Øyvind Kolås 31 Dec 18:05
  GEGL 0.0.22 Hubert Figuiere 31 Dec 18:56
   GEGL 0.0.22 Sven Neumann 01 Jan 16:15
  ok made GeglColor primarily operate on double arguments Nicolas Robidoux 03 Jan 20:18
   ok made GeglColor primarily operate on double arguments Øyvind Kolås 04 Jan 00:41
    GSoC suggested project: OpenGL GPU resampling in GEGL Nicolas Robidoux 20 Mar 07:32
     GSoC suggested project: OpenGL GPU resampling in GEGL Øyvind Kolås 20 Mar 11:58
Øyvind Kolås
2008-12-31 18:05:31 UTC (about 16 years ago)

GEGL 0.0.22

GEGL 0.0.22
???????????
GEGL (Generic Graphics Library) is a graph based image processing framework.

GEGL provides infrastructure to do demand driven, cached, non destructive image editing of larger than RAM rasters. Through babl it provides support for a wide range of color models and pixel storage formats for input and output.

This is a release introduces a feature freeze the current feature set perhaps with some
features will become the basis for the first 0.1.0 release, the APIs which will receive
some changes (removal of feature) is GeglPath, apart from that most of the current API
seems to be sufficient for a quite wide range of uses. After the introduction of
gegl_node_add_child and gegl_node_remove_child calls gegl_node_adopt_child call might be removed. Please note that documentation of unstable APIs is not complete.

Happy new year.

/pippin

Changes in this release ???????????????????????
• GeglOperation
• operation names are now prefixed, the ops in GEGL use 'gegl:' as prefix. • gegl:opacity - combine value and aux mask input when both are available. • gegl:src-in - deal correctly with extens. • gegl:path - new op covering the stroke/fill needs of SVG. • deprecated gegl:shift, the affine familiy of operations now uses the same fast code paths for integer translations. • GeglBuffer
• Profiling motivated speed ups in data reading/writing. • Remove left-over swapfiles from dead processes at startup. • GeglNode
• made gegl_node_add_child and gegl_node_remove_child public API. (#507298) • GeglPath
Vector path representation infrastructure, supporting poly lines and beziers by default, the infrastructure allows extensions from applications with other curve types (smooth curves, spiro curves and others.).

The improvements in GEGL in this release brought to you by: Hubert Figuiere, Sven Neumann, Øyvind Kolås, Michael Natterer, Kevin Cozens, Sam Hocevar, Martin Nordholts, Manish Singh, Étienne Bersac and Michael Schumacher.

Where to get GEGL ?????????????????
GEGL and it's dependencies babl and glib can be fetched from:

ftp://ftp.gimp.org/pub/babl/0.0/babl-0.0.22.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.0/gegl-0.0.22.tar.bz2 ftp://ftp.gtk.org/pub/glib/2.18/glib-2.18.1.tar.bz2

The integrity of the tarballs can be verified with:

sha1sum *.bz2 9de50fb5833f41691f50f6e735d6422aad52ea94 babl-0.0.22.tar.bz2 de684d4c8d9eaa9b7e283c55c5f779e5bdabee78 gegl-0.0.22.tar.bz2 d34a30cfccc8322dfe4198d26cf6bfc0210f141b glib-2.18.1.tar.bz2

Where to get more information about GEGL ???????????????????????????????????????? More information about GEGL can be found at the GEGL website http://www.gegl.org/

Hubert Figuiere
2008-12-31 18:56:14 UTC (about 16 years ago)

GEGL 0.0.22

On Wed, 2008-12-31 at 17:05 +0000, Øyvind Kolås wrote:

d34a30cfccc8322dfe4198d26cf6bfc0210f141b glib-2.18.1.tar.bz2

Do we really need that recent version of glib? Because that mean only the very latest distro users can use GEGL. No openSUSE 11.0 for example (released just before GUADEC to give a time frame)

Hub

Sven Neumann
2009-01-01 16:15:37 UTC (about 16 years ago)

GEGL 0.0.22

On Wed, 2008-12-31 at 12:56 -0500, Hubert Figuiere wrote:

On Wed, 2008-12-31 at 17:05 +0000, Øyvind Kolås wrote:

d34a30cfccc8322dfe4198d26cf6bfc0210f141b glib-2.18.1.tar.bz2

Do we really need that recent version of glib? Because that mean only the very latest distro users can use GEGL. No openSUSE 11.0 for example (released just before GUADEC to give a time frame)

GEGL 0.0.22 does not depend on glib 2.18, it only needs glib >= 2.16.1. But of course you are encouraged to use the latest stable GLib release and that's probably why it's linked from the release notes.

Sven

Nicolas Robidoux
2009-01-03 20:18:00 UTC (about 16 years ago)

ok made GeglColor primarily operate on double arguments

Hello Øyvind:

Do the recent svn changes imply that doubles should be used for pixel data in gegl-buffer operations instead of floats? (Now or later?)

Nicolas Robidoux Universite Laurentienne

Øyvind Kolås
2009-01-04 00:41:27 UTC (about 16 years ago)

ok made GeglColor primarily operate on double arguments

On Sat, Jan 3, 2009 at 7:18 PM, Nicolas Robidoux wrote:

Do the recent svn changes imply that doubles should be used for pixel data in gegl-buffer operations instead of floats? (Now or later?)

The move to doubles in the external API is to make it consistently more future proof. The internal representation is independent, the external format should be be of high precision and doubles are needed for variable arguments anyways.

I am still going to look into some issues where internal floating point use is exposed in the application facing parts of the public GEGL API (this is the same API that should be provided by the language bindings for GEGL).

The operation creation API should be considered separate from the public API a move to doubles for writing operations (buffer acccess) could be done internally
if that would be needed if a fixed point, higher precision floating point, GPU based
or other form of backend or fork. At the moment I do not see that as likely even though this change to the public API change would make this possible.

/Øyvind K

Nicolas Robidoux
2009-03-20 07:32:26 UTC (almost 16 years ago)

GSoC suggested project: OpenGL GPU resampling in GEGL

Hello:

Someone has expressed interest in the following project:

I would like to double check that this project makes sense. If the student is committed to GPU programming for GEGL, is there something else which would be "better" (given that if it falls outside of resampling I won't mentor it, and also that really I have no clue about how to build a GEGL-GPU interface)?

Here is a cut and paste from

http://wiki.gimp.org/gimp/SummerOfCode2009ideas#head-c616d78ee5dc03ae28707de7fadf0b1fa8ecfb66

OpenGL GPU resampling in GEGL

*

Suggested by: Nicolas Robidoux (nicolas) *

Mentored by: Nicolas and Minglun Gong and whoever else wants to help

The nohalo (gegl-sampler-sharp.c) resampler has been successfully programmed in HLSL/DirectX. For DVD to HDTV upsampling, it gets a performance comparable to hardware bilinear (between 12% and 93%). As a baby step toward GEGL rendering on the GPU, it may be a good thing to move nohalo to OpenGL and then interfacing the GPU version with GEGL. The "higher" versions of nohalo are currently being programmed in HLSL, so these could be moved to OpenGL + GEGL as well. Yet another variant, snohalo, particularly suitable for "text like" CG graphics, is also easily implemented.

(Nicolas: I don't have any idea how to interface GPU-based resampling with GEGL. This project is likely to require a very resourceful student and/or the input of more "senior" GEGL developers.)

Needed skills: OpenGL + GPU programming + C programming + GObjects + the usual (svn etc)

nicolas

Øyvind Kolås
2009-03-20 11:58:46 UTC (almost 16 years ago)

GSoC suggested project: OpenGL GPU resampling in GEGL

On Fri, Mar 20, 2009 at 6:32 AM, Nicolas Robidoux wrote:
imp.org/gimp/SummerOfCode2009ideas#head-c616d78ee5dc03ae28707de7fadf0b1fa8ecfb66

OpenGL GPU resampling in GEGL

   *

     Suggested by: Nicolas Robidoux (nicolas)    *

     Mentored by: Nicolas and Minglun Gong and whoever else wants to help

The nohalo (gegl-sampler-sharp.c) resampler has been successfully programmed in HLSL/DirectX. For DVD to HDTV upsampling, it gets a performance comparable to hardware bilinear (between 12% and 93%). As a baby step toward GEGL rendering on the GPU, it may be a good thing to move nohalo to OpenGL and then interfacing the GPU version with GEGL. The "higher" versions of nohalo are currently being programmed in HLSL, so these could be moved to OpenGL + GEGL as well. Yet another variant, snohalo, particularly suitable for "text like" CG graphics, is also easily implemented.

(Nicolas: I don't have any idea how to interface GPU-based resampling with GEGL. This project is likely to require a very resourceful student and/or the input of more "senior" GEGL developers.)

Needed skills: OpenGL + GPU programming + C programming + GObjects + the usual (svn etc)

Doing this basically requires writing a GPU backend for GeglBuffer and having the plan and understanding for how to integrate GEGL with the GPU. Adding custom resamplers like this sounds like a small thing compared to the other work that would need to be done to enable starting working on the specific topic.

/Øyvind K.