On Wed, Sep 1, 2010 at 9:47 AM, Rupert Weber wrote:

Hi,

trying to get to know babl (wrt the LCH layer modes), quite a few questions came up that made me wish for a babl 'Conversion implementor's guide'. (If such a document exists just disregard the rest of this mail -- but please show me where).

So maybe the best I could do for starters is write such guide -- as long as I still remember what the questions are of someone newly confronted with babl. But I'll need a little help with the answers... ;o)

Sounds like a great idea!

First, two general questions about babl: - babl decides which conversion to use, based on speed and accuracy. Is   that a build-time or run-time decision?

IIRC Oyvind said this is checked at run time.

Adding conversions to babl:
I haven't gone deep into the babl source yet (and hope I won't have to), so the following is a mixture of my best guesses and some open questions. I'll be glad for 'yes/no' confirmations and of course any additional info/answers:

- Create source file in subdirectory 'extensions' and add it to   extensions/Makefile.am. The rest is automagic.

True.

- Source must have 'int init (void)' function which announces/registers   the new conversions:

Seems true to me, but I haven't tested it yet.

  - Register color model and its components using        babl_component_new()
         [ what about "luma", "chroma", "alpha"? ]

AFAICS those are misleading -- I think they are booleans (ie 'this is a luma channel'* (L of LAB/LCH or Y of (graY)), 'this is a chroma channel' (A/B of LAB; Cb/Cr of YCbCr), 'this is an alpha channel' (.. alpha) )

Grepping through the appropriate files, you can see that:

plain R,G,B are registered with LUMA and CHROMA, without ALPHA. Ra,Ga,Ba are registered with all 3;
R', G', B' are registered similar to R,G,B; R'a, G'a, B'a are registered similar to R,G,B (this seems to be a copy/paste error; AFAICS they should also have the ALPHA flag)

Naive CMYK are registered without any flags - this probably reflects the naivety.

All Y variants are registered as only LUMA (including the premultiplied variants). This seems wrong also; perhaps Oyvind can shed some light on this.

LAB /LCH A,B+C,H channels are registered with CHROMA flag, which makes sense, but L isn't registered with LUMA. (I don't really understand that, either)

* AFAICS, 'luma' is meant in a loose sense here.."this channel encodes brightness in some sense" not "this channel encodes X specification of brightness"

       babl_model_new()
         [ lots of parameter possibilities... ]

    [ naive-CMYK e.g. registers "CMYK" but not "RGBA".

RGBA is the responsibility of model-rgb.c , IIRC. I'm not sure what it was you meant to say here.

I assume RGBA is
      a core-format that can always be relied on to exist? Is there a       list of such formats?

I figured that
http://gegl.org/babl/#Features (under the 'vocabulary' heading) had such a list (click 'color models' and 'pixel formats'); maybe not 'forever', but 'for the foreseeable future.'

The 'extensions' dir is a little confusing. I interpret the this 'canonical' set of extensions as implying additional color models that are virtually fixtures (though the implementation of them may vary -- eg. the LCH being implemented in both CIE.c and gggl-lies.c, with the latter being ignored at runtime due to lesser quality.)

      PS: babl-core.c suggests that RGBA (+ its components) is the only           hardcoded model, along with the PAD component and the double           type.
      PPS: babl-base.c has additional types and models:            types: float/u8/u16/u32
           models: (plus respective components Ra/R'/R'a etc.)                     RGB: RGB/RaGaBaA/R'G'B'/R'G'B'A/R'aG'aB'aA                    Gray: Y/YA/YaA/Y'/Y'A/Y'aA                   YCbCr: YCbCr/YCbCrA... now it gets confusing. Where                          the hell does "y'" come from?

Y is not registered by the YCbCr module because the Gray module already registered it. That's fine (component lookups are indirected through the BABL core to allow things like this.). (if you have a component with actually different meaning but the same mnemonic letter/s, that's a different issue.)

As far as I can see, you probably only want to:

1. register two new formats "CIE LCH(ab) u16" and "CIE LCH(ab) alpha u16"; 2. register some conversions from/to eg "R'G'B'A u8" (it should be pretty easy to also make versions for "RGBA u8", too). You might want to consider defining conversions from the grey formats ("Y'" ,"Y","Y'a","YA") too; I was just thinking about how your LCH layer modes act like Normal mode when applied to Grayscale images. 3. (no need to register new models or components)

Hope that helped :)

On 09/09/2010 12:12 AM, Rupert Weber wrote:

I put up a first draft at
http://leguanease.org/gimp/babl/docs/writing-extensions.html

That's pretty nice, could you provide a patch against the docs part in babl? http://git.gnome.org/browse/babl/tree/docs

Thanks!

/ Martin

On Thu, Sep 9, 2010 at 10:18 AM, Rupert Weber 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.

On Fri, Sep 10, 2010 at 11:55 PM, Rupert Weber wrote:

Something else I don't understand about models/formats:

If babl automatically creates a double-format for every registered model, how can there be models without a double-format? Namely RaGaBaA, RGB, R'G'B', YaA, Y'A, and Y'?

Looking at the code babl doesn't create a double-format, but when registering a color model conversions to/from a (perhaps synthesized) double format is provided to be able to regression test.

Also, why are there so many empty spots on the introspection? E.g. Lab float/u8/u16: shouldn't babl find it's own way from double to float? And type conversions to/from u8 and u16 are supplied by CIE.c. (Actually, those are buggy in several ways, but fixing it doesn't help)

Empty spots in what, if you are referring to http://gegl.org/babl/BablFishPath.html then the empty spots are the spots where babl is finding its own way, the single dots are where there are direct conversions and the bars of varying vertical height indicate how many steps a multi step conversion takes.

The 8bit / 16bit data types for CIE lab are very different beasts from the 8bit types used for sRGB and will be used when those pixel formats are used.

/Øyvind K.

On Sat, Sep 11, 2010 at 1:21 PM, Rupert Weber wrote:

On 09/11/2010 10:14 AM, Øyvind Kolås wrote:

Looking at the code babl doesn't create a double-format, but when registering a color model conversions to/from a (perhaps synthesized) double format is provided to be able to regression test.

I'm sure you think this all totally obvious, but it's actually really confusing. ;o)

An example:
- I registered a color model "HSV" and its components, but no format. - Now I can successfully register a conversion between "RGBA" and  "HSV", all components are (implicitly) double - BablFishPath.html shows a format "HSV double" - But "HSV double" doesn't actually exist as a format. Trying to  register a conversion to/from babl_format("HSV double") gives  an error: babl_format("HSV double"): not found - In contrast, when I _use_ babl (i.e. not inside babl)  babl_format ("HSV double") works just fine. - Then again, babl_format ("RGB double") always fails, both inside  babl and in userland.

Maybe there is a red line somewhere in there which I fail to see, but right now I'm just hopelessly confused and wouldn't know how to sanely describe the situation in the docs.

My knee-jerk proposition would be: Automatically register a double format for every model that is registered. Is there any downside to that?

I do not see a downside to this, it would probably result in a net code size reduction which is only a good thing.

(I thought before that happens already but failed to realize that I had followed the call hierarchy to somewhere in babl/tests)

Empty spots in what, if you are referring to http://gegl.org/babl/BablFishPath.html then the empty spots are the spots where babl is finding its own way,

I still don't understand that. What is 'its own way'? E.g. the "CMYK float" row has only empty spots. Picking one of them, I get e.g. 'Reference CMYK float to CIE Lab u16' in the popup window. How can babl possibly find its own way from CMYK to CIE Lab u16 without hopping over several extension-supplied conversions?

When there are no direct conversions available, and no way to use multiple registered "linear" conversions to get from the source format to the destination format babl uses the generic conversion code in

http://git.gnome.org/browse/babl/tree/babl/babl-fish-reference.c

It can do this because a BablFormat contains knowledge of the color model used, the permutation (order) of the components as well as the types of the individual components.
This reference conversion is bound to be quite a bit slower than a direct conversion between two pixel formats, since it contains intermediate conversions to the relevant double pixel formats, it takes the permutation of the components into account etc. This reference conversion is also used to verify that shortcuts registered in extensions actually provide sufficiently accurate results.

-

Those two even I understood. ;) But I'm still riddling over the red bars.

Something changed making the stats output a little bit less useful than it used to be, only conversions that are using the reference fishes[1] and are used to convert a "significant count" of pixels should be marked like this, as an indication that the given conversion is a likely bottleneck in processing.

1: The reason for both babls name, and for classes to be called fishes can be found in the hitchhikers guide to the galaxy http://en.wikipedia.org/wiki/Babel_fish_%28leech-like%29#Babel_fish

On Sat, Sep 11, 2010 at 8:28 PM, Rupert Weber wrote:

So it's a three-liner now. Hope it's ok that I include it here. I decided to insert a declaration instead of pulling up the static function to the top, so the patch wouldn't look like stuff has changed that hasn't. If you want it the other way, let me know or just change it. Either way,

Thank you, commited to git.

/Øyvind K.

On Mon, Sep 20, 2010 at 12:49 AM, Rupert Weber wrote:

More questions...

1. C standard The docs state "ANSI C" as a feature. Is that actually meant in the strict sense of C89, not C99? Does that hold for (babl-)extensions as well? I'm specifically thinking about inline and inttypes.h.

GIMP tends to claim C89 compatibility; we shouldnt assume more modern language standard than GIMP does.

2. Clipping
CIE.c currently clips RGB results to 0.0-1.0, i.e. sRGB. This leads to any inter-CIE conversion which is routed through RGBA-double to be clipped to sRGB. Is that by design or a bug?

To support HDR/wide gamut workflows as well as possible, I think no clipping should occur in babl, apart from when it is unavoidable; like it is when converting to 8bit fixed-point.

/Øyvind K.

On 09/30/2010 01:02 AM, Øyvind Kolås wrote:

On Mon, Sep 20, 2010 at 12:49 AM, Rupert Weber wrote:

More questions...

1. C standard The docs state "ANSI C" as a feature. Is that actually meant in the strict sense of C89, not C99? Does that hold for (babl-)extensions as well? I'm specifically thinking about inline and inttypes.h.

GIMP tends to claim C89 compatibility; we shouldnt assume more modern language standard than GIMP does.

Hi Øyvind

What problems do you expect us to get if we begin to rely on an 11 year old standard instead of a 21 year old standard?

At what time has enough time passed for us to feel comfortable using the improvements in C99?

/ Martin

On Thu, 2010-09-30 at 07:36 +0200, Martin Nordholts wrote:

GIMP tends to claim C89 compatibility; we shouldnt assume more modern language standard than GIMP does.

Hi Øyvind

What problems do you expect us to get if we begin to rely on an 11 year old standard instead of a 21 year old standard?

At what time has enough time passed for us to feel comfortable using the improvements in C99?

As soon as enough compilers support it so that we don't loose platform compatibility.

What specific C99 features are we talking about at all? Is there a specific feature that you guys would like to use?

Sven

On 09/30/2010 11:11 AM, Sven Neumann wrote:

On Thu, 2010-09-30 at 07:36 +0200, Martin Nordholts wrote:

GIMP tends to claim C89 compatibility; we shouldnt assume more modern language standard than GIMP does.

Hi Øyvind

What problems do you expect us to get if we begin to rely on an 11 year old standard instead of a 21 year old standard?

At what time has enough time passed for us to feel comfortable using the improvements in C99?

As soon as enough compilers support it so that we don't loose platform compatibility.

What specific C99 features are we talking about at all? Is there a specific feature that you guys would like to use?

I like in particular

* designated initializers

Nice to have

* // comments

Using /* */ for documentation and // for comments increases code readability since different comment semantics gets different syntax

* mixed declarations and code

Because variables can be declared closer to where they are used

* new block scopes for selection and iteration statements

So one can have for (int i = 0; i < N; i++) i.e. not having to declare 'i' beforehand

* macros with a variable number of arguments

Allows us to remove some hacks to handle compilers without such support

* trailing comma allowed in enum declaration

Nicer diffs

Regards, Martin

On Fri, 2010-10-01 at 08:20 +0200, Martin Nordholts wrote:

What specific C99 features are we talking about at all? Is there a specific feature that you guys would like to use?

I like in particular

* designated initializers

Nice to have

Indeed.

* // comments

Using /* */ for documentation and // for comments increases code readability since different comment semantics gets different syntax

// comments are just plain ugly. I don't follow you on this one, but I could probably live with it.

* mixed declarations and code

Because variables can be declared closer to where they are used

That leads to very ugly code. You can always open a new scope if you want to declare local variables. And perhaps you should split your code into smaller functions. I am strongly against this and think we should definitely continue to compile with '-Wdeclaration-after-statement' even if we decide that C99 code should in general be allowed.

* new block scopes for selection and iteration statements

So one can have for (int i = 0; i < N; i++) i.e. not having to declare 'i' beforehand

Yes, that is a nice feature.

Sven

On 10/02/2010 12:11 AM, Sven Neumann wrote:

On Fri, 2010-10-01 at 08:20 +0200, Martin Nordholts wrote:

* mixed declarations and code

Because variables can be declared closer to where they are used

That leads to very ugly code. You can always open a new scope if you want to declare local variables. And perhaps you should split your code into smaller functions. I am strongly against this and think we should definitely continue to compile with '-Wdeclaration-after-statement' even if we decide that C99 code should in general be allowed.

I can agree with that it is often nicest to have all declarations at the beginning of a scope, but I don't think we should be so categoric that we compile with -Wdeclaration-after-statement. Sometimes, you get the nicest code by having declarations in the middle of scopes. At least we will have the option. Introducing an artificial level of indentation just because we need a new scope is IMO much uglier.

/ Martin