Re: [Gegl-developer] babl docs

2010-09-09 Thread Rupert Weber
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

___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer


Re: [Gegl-developer] babl docs

2010-09-09 Thread Øyvind Kolås
On Thu, Sep 9, 2010 at 10:18 AM, Rupert Weber g...@leguanease.org 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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer