Re: babl docs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 1, 2010 at 9:47 AM, Rupert Weber <gimp@xxxxxxxxxxxxxx> 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 :)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer



[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux