On Tue, Jan 25, 2011 at 3:30 PM, Jan Rabusic <jrabusic@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
