On Mon, Jan 10, 2011 at 8:01 PM, Jan Rabusic <jrabusic@xxxxxxxxx> wrote: > Hi, my name is Jan and I am a student of the University of West Bohemia in the > Czech Republic. This year I am writing my bachelors work - a program for > advanced color correction. GEGL we found very useful library. But our target is > a program that will also work with images in color spaces other than RGBA. > So I have some questions about color spaces and bit depths: > 1) Oftentimes you write that most operations work in the RGBA color space. If I > understand correctly, GEGL care about the transfer to the native color space > (format) in the "prepare" (such as in operation "brightness-contrast"). In GEGL > are some operations that are not limited to RGBA as "invert"(at least contains > no "prepare"). Although there is no conversion to native RGBA, but this > operation algorithm uses three channels, which inverts and one that is not > inverted. So it would work properly with RGBA (but not in CMYK), how to ensure > that this format will be the input? (is there any other mechanism which > automaticaly converts formats to RGBA than "prepare"?) At the moment, GEGL is considering most color formats as subsets of what is expressible in RGBA, and chooses to implement most other color spaces (and thus pixel formats) through implict conversions done with babl. This is true for any three-dimensional color space and given floating point unbounded gamuts thus is true for XYZ, Yuv/YCbCr, RGB, gray scale, HSL, HSV and other similar color models, with these color models and babl available ops for GEGL choose the pixel representation most convenient to implement the given algorithm. Most (perhaps all?) current GEGL operations specify the format they are going to output in prepare() (this is so that GEGL will know which pixel format to create an output buffer for) the invert op not containing a "prepare" means that the super class' implementation will be used. Prepare doesn't do any actual conversion. For the point process operations the formats specified in prepare are the formats that data is converted to (or if possible wrt memory alignment and type directly accessed as) around the inner loop processing function. In more regular filter ops the user is expected to use the GeglBuffer API (gegl_buffer_get, gegl_buffer_set and similar and pass in the formats for processing manually, possibly ignoring what has been set in prepare(). It would be possible to extend GEGL in various ways to ensure that at least core operations (compositing, gaussian blur and transformations, perhaps some arithmetic) also works with CMYK by special casing the handling of such pixel formats. Yet another option to special casing for instance CMYK is to extend babl with annotations about components and their role in the color model they are used in (the start of such annotations actually ended up in babl; but it is not complete). This would allow writing generic processing functions that deal with the components for arbitrary color models/pixel formats. These options are not mutually exclusive and extensions to GEGL if done cleanly to achieve this functionality would be welcome. >From an API usage perspective GEGL provides an API that should remains stable as more complex features are added to it; and perhaps even large parts of the internals are rewritten. (the API of plug-ins is considered to be a different more fluctuating entity than the API for applications using GEGL.) For photos In most cases where people are manipulating photos in CMYK I consider that to be misguided and premature "corrections". Photos should be kept in RGB for as long as possible in work flows and and only separated to CMYK when there is an actual graphic design need for it (vector elements reusing a CMYK color picked from a color photo,.. not "adjusting colors as virtual ink levels"). > 2) What color spaces and bit depths GEGL buffer supports? They are all that are > defined in the BABL? All that are defined in babl, and babl is dynamically extendable with both color models and data types. The data structures in GEGL (like GeglBuffer) even support babls CMYK and buffers with arbitrary number of components, even though they cannot be sanely converted back and forth to RGB. Adding a new format to babl (through a plug-in or even from a GEGL op or an application using GEGL) would add support for that format to GEGL. ICC profile backed color spaces can be (and has in ad-hoc code been) added to babl, or applications using GEGL/babl can choose to "normalize" colors to a known and well defined color model like those pre-registered in babl. HopeThisHelps /Øyvind K. -- «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
