internal structure of 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.
| internal structure of GEGL | Jan Rabusic | 25 Jan 15:30 |
| internal structure of GEGL | " | 25 Jan 16:01 |
internal structure of GEGL
Hi,
it's me again. This time I would like to ask you about the internal
structure of GEGL.
You may wonder, that I am asking for so trivial a question that is answered in the documentation. But the documentation says to me "What a part of Library does and how can I call it", but not "Where can I define new types of atributes, which are used to call an operation?" GEGL is a quite robust library, so it isn't easy to understand its structure, its own data types, etc.. So it would really help, if there is some more detailed documentation, is there any? Or if you know about some book which describes sheme, on which is GEGL based.
For example my problem: I would like to extend color operations. I would like to rewrite every operation which depends on color model of input (invert, brightness-contrast, etc.) to have in arguments an "color model format", and according to this variable would be perform the appropriate version of the operation. Example: I have sRGB 8bit integer data and I would like to call invert, so ...(gegl, "operation", "gegl:invert", "c_m_format", "sRGB 8bit", NULL) would call invert for 8bit and three channels... - problem is how and where should I define this "c_m_format"? - Second question about this is: can be "get_gegl_buffer_format" usefull for this? can I call it in operation invert on its input? if yes, what points the pointer Babl*, which is returned? an array of chars?
Thanks a lot for any advice, information, source of informations, book, etc.
Jan
internal structure of GEGL
On Tue, Jan 25, 2011 at 3:30 PM, Jan Rabusic wrote:
For example my problem: I would like to extend color operations. I would like to rewrite every operation which depends on color model of input (invert, brightness-contrast, etc.) to have in arguments an "color model format", and according to this variable would be perform the appropriate version of the operation. Example: I have sRGB 8bit integer data and I would like to call invert, so ...(gegl, "operation", "gegl:invert", "c_m_format", "sRGB 8bit", NULL) would call invert for 8bit and three channels...
The working space of most of GEGLs processing ops are by design 32bit linear light RGB, this allows both headroom and footroom allowing for intermediate results that go beyond the 0.0-1.0 / 0-255 range, which is neccesary for some operations like unsharp mask and provides more predictable results than having separate implementations for a wider range of pixel formats, babl is used as a universal translator to implicitly convert between various pixelformats/colorspaces. See http://gegl.org/babl/ for more details about babl.
For some of the color operations currently used in GIMP doing the processing in 32bit float with conversions back and forth from 8bit is already as fast as GIMPs old code operating only in 8bit, adding code to deal with gamut limited formats seems like something that would bring mostly problems and not many obvious benefits.
- Second question about this is: can be "get_gegl_buffer_format" usefull for this? can I call it in operation invert on its input? if yes, what points the pointer Babl*, which is returned? an array of chars?
Do you mean gegl_buffer_get_format ? This does return a reference to an opaque data structure that can be queried for information with the babl API, see that babl documentation/headers for further insight into what can be done with it.
Adding paralell implementations that specially deal with other color models, or code paths that deals generically with multi component color models is something I would primarily see as beneficial for CMYK - and at least initially that is something that I would not consider necessary during processing of photos/drawings, but something to be done after GEGL/GIMP has dealt with the image when the final printing color space is known and well defined. Most users desiring a CMYK mode should be satisfied by working in properly color managed RGB with CMYK soft-proofing, and perhaps attaching an ICC profile later, perhaps separating to CMYK at export if the software/hardware used further down a printing pipeline does not support PDF/X.
/Øyvind Kolås
«The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ _______________________________________________ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
