On Thu, Sep 9, 2010 at 10:18 AM, Rupert Weber <gimp@xxxxxxxxxxxxxx> wrote: > On 09/09/2010 08:03 AM, Martin Nordholts wrote: >> That's pretty nice, could you provide a patch against the docs part in babl? >> http://git.gnome.org/browse/babl/tree/docs > > Sure: https://bugzilla.gnome.org/show_bug.cgi?id=629146 Yep it is nice to get someone to document some of this process :), I wonder if you can be tricked into documenting how to interpret the statistics in /tmp/babl-stats that occur when the environment variable BABL_STATS is set as well; to guide the understanding of which slow paths are being taken decreasing overall performance. Comments for the editnotes, it would have been easier to reply to these, in context if you asked them as questions here on the mailinglist rather than embed them in the document. linear, plane, planar "linear" is for converting a buffer of n pixels with a given pixel format, the pixels are expected to contain the components packed/interleaved/chunky in the order specified in the pixel format. "plane" is for converting a single plane, this can be used internally by babl when constructing reference/fallback conversions, it allows doing processing on one and one component and as guessed with individual pitch changes (to skip the other components if needed). "planar" is for converting full images where the components might be stored separately, like it is done for some YCbCr formats in video compression (where the dimensions of the images for the Cb and Cr components might be smaller than the Y image), this feature in babl is not used by GEGL and migh not be completely functional. ... yes, you should re-register color models and used pixel formats in extensions that are not present in the babl-base, since the order extensions are loaded in are not guaranteed. ... the use of babl_type_new and ... "integer", "unsigned" indeed seems to be wrong. .. the return value of conversion functions was intended to be the number of samples actually converted, the value is not really used anywhere in babl though and could probably be removed and be made void. .. the "chroma", "alpha" and "luma" flags have no meaning inside babl but can be useful in determining behavior for image processing algorithms in a manner that is independent of the actual color model used. At one point it was also used to detmine whether conversion would incurr a loss of "features" thus blacklisting possible multi-step conversion paths, this is now achieved through other means. /Ø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
