Re: [Gegl-developer] babl docs
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 -- My GIMP Blog: http://www.chromecode.com/ Automatic tab style and removed tab title bar ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On 10/01/2010 08:20 AM, Martin Nordholts wrote: * mixed declarations and code Because variables can be declared closer to where they are used If only I hadn't brought up the topic... ;) I think that's a terrible concept which actually makes code very difficult to read. Instead of having one known place to look for a declaration, they'll be sprinkled all over. Just like small indents, they are just another tool for covering up the fact that a function has grown too large and should be split into smaller units. Maybe we can just stick with C89 and autoconf'ed extensions? ;o) Rupert ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On 09/29/2010 06:08 PM, Rupert Weber wrote: On 09/15/2010 05:11 PM, Rupert Weber wrote: I just found out the hard way what model-to-model conversions are about: 1. They can only be from/to RGBA (that part was easy) 2. For every new model, model-to-model conversions *must* be supplied. Those are the reference conversions which babl assumes to have an error of 0. Replacing those by the respective double format-to-format conversions doesn't work. Posted an update to the guide to https://bugzilla.gnome.org/show_bug.cgi?id=629146 and also directly viewable at http://leguanease.org/gimp/babl/docs/extension-guide-main.html While I can't do much about lack of authoring/didactic skill, I'm of course grateful of any suggestions; but mainly I want to be sure it's at least factually correct. The goal of the document is to enable anyone to write extensions, maybe with a peek at existing extensions for reference, but without having to go into the source code of babl itself. Rupert ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
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 ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
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 ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On 09/15/2010 05:11 PM, Rupert Weber wrote: And now that double formats exist for all models, shouldn't we consider deprecating model-to-model conversions alltogether? ok, scratch that. (I'll just keep talking to myself...) I just found out the hard way what model-to-model conversions are about: 1. They can only be from/to RGBA (that part was easy) 2. For every new model, model-to-model conversions *must* be supplied. Those are the reference conversions which babl assumes to have an error of 0. Replacing those by the respective double format-to-format conversions doesn't work. I'll have to amend the guide accordingly. What I haven't tried yet: What happens if two extensions supply model-to-model conversions for the same format, but with different results? Rupert ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
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. 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? Should there be - no clipping (not even to scRGB) - clipping to scRGB (CIE-to-CIE, e.g. might suffer) - clipping to sRGB, as it is now? Who should be responsible for clipping? - the conversion function? (has no knowledge of final conversion target) - babl? (at least knows final target) - the application using babl? Just some questions I stumbled over today. ;) BTW, sorry for the duplicate RGBA-double bug. No idea how I could miss that. Regards Rupert ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On 09/14/2010 04:58 PM, Rupert Weber wrote: Are planar and non-planar versions of one (equally named) format supposed to coexist? False alarm as far as I can tell. Sorry about the fuzz. All in all, the planar formats and conversions are still a bit mysterious to me: E.g., how do planar formats and linear conversions go together? And now that double formats exist for all models, shouldn't we consider deprecating model-to-model conversions alltogether? From what I can tell, all they do is save typing double twice, for the cost of additional on-the-fly format- and conversion-generation (in fact, a large part of conversion_new()) -- and potential for confusion. Regards Rupert ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
Posted an updated version of the docs to http://leguanease.org/gimp/babl/docs/extension-guide-main.html Posting those on bugzilla every time feels a bit heavyweight as long as it isn't done yet. And now that I also posted an updated patch for the reregistering problem to https://bugzilla.gnome.org/show_bug.cgi?id=629326 I think I might have botched that one. Are planar and non-planar versions of one (equally named) format supposed to coexist? If so, please disregard the patch as it will mess everything up. (I just hope not, as it would make the patch so much more complicated -- won't be able to take a deeper look at the code myself before tomorrow, though) Regards Rupert ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On Sat, Sep 11, 2010 at 8:28 PM, Rupert Weber g...@leguanease.org 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. -- «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
Re: [Gegl-developer] babl docs
On Fri, Sep 10, 2010 at 11:55 PM, Rupert Weber g...@leguanease.org 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. -- «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
Re: [Gegl-developer] babl docs
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 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? 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. Those two even I understood. ;) But I'm still riddling over the red bars. Regards Rupert ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On Sat, Sep 11, 2010 at 1:21 PM, Rupert Weber g...@leguanease.org 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 -- «The future is already here. It's just not very evenly distributed» -- William Gibson ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On 09/11/2010 03:06 PM, Øyvind Kolås wrote: I do not see a downside to this, it would probably result in a net code size reduction which is only a good thing. ok. For a moment, I thought that might be a trivial one-liner; but all I got was a whole lot of 'BablBase: babl-type.c:254 babl_type() babl_type(double): hmpf!'... oh, well. 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 [...] so an empty cell means something like 'found a path, but with detours that involve taking apart pixels and converting single components'? 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. Hmm. What I noticed now is that the red bars change their position with every regeneration of the document. Also single conversions (dots) are sometimes replaced by red bars. I still don't see what that tells me, but I'll ignore that for now. Rupert ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On 09/11/2010 07:35 PM, Rupert Weber wrote:
ok.
For a moment, I thought that might be a trivial one-liner; but all I got
was a whole lot of 'BablBase: babl-type.c:254 babl_type()
babl_type(double): hmpf!'... oh, well.
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,
Regards
Rupert
From 2ef6bb3dfaf596e8361811b24dd2bcc1eb7ec8f6 Mon Sep 17 00:00:00 2001
From: Rupert Weber g...@leguanease.org
Date: Sat, 11 Sep 2010 21:17:34 +0200
Subject: [PATCH] create double format for every model
Changes babl_model_new() to create a respective double format
for every new registered model.
That way applications and extensions can rely on the double
format to always exist.
---
babl/babl-model.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/babl/babl-model.c b/babl/babl-model.c
index eb7eee4..4766b3b 100644
--- a/babl/babl-model.c
+++ b/babl/babl-model.c
@@ -23,6 +23,8 @@
#include babl-internal.h
#include babl-db.h
+static Babl *construct_double_format (Babl *model);
+
static int
babl_model_destroy (void *data)
{
@@ -169,6 +171,7 @@ babl_model_new (void *first_argument,
{
babl = model_new (name, id, components, component);
babl_db_insert (db, babl);
+ construct_double_format (babl);
}
else
{
@@ -224,7 +227,7 @@ static Babl *construct_double_format (Babl *model)
int i;
argument[args++] = model;
- argument[args++] = babl_type (double);
+ argument[args++] = babl_type_from_id (BABL_DOUBLE);
for (i = 0; i model-model.components; i++)
{
--
1.7.0.4
___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
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
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
Re: [Gegl-developer] babl docs
I put up a first draft at http://leguanease.org/gimp/babl/docs/writing-extensions.html (I think that's easier to look at than as a patch to babl) It's still very incomplete. I put some comments and questions in red boxes. There is no integration with current menus yet. Glad for any comments and clarifications. I also did quite a bit of change to css, hope you like the general idea: - also not done yet and doesn't look quite the same, but close. The goal is to have as much of the formatting tied to standard elements, not classes. - split up css into 'base.css' and 'special.css' - base.css contains only options for standard html elements, no classes or ids - special.css contains all options for classes and ids. The idea was to make it easier to add any html documents without having to add a lot of classes first. (And porting existing html to another css should be simpler that way, too) Regards Rupert ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
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 -- My GIMP Blog: http://www.chromecode.com/ Automatic tab style and removed tab title bar ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On Wed, Sep 1, 2010 at 9:47 AM, Rupert Weber g...@leguanease.org 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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] babl docs
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 implentor'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) 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? - What is the reference for judging accuracy? 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. - Source must have 'int init (void)' function which announces/registers the new conversions: - Register color model and its components using babl_component_new() [ what about luma, chroma, alpha? ] babl_model_new() [ lots of parameter possibilities... ] [ naive-CMYK e.g. registers CMYK but not RGBA. I assume RGBA is a core-format that can always be relied on to exist? Is there a list of such formats? 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? PPPS: Maybe I should just compile w/o extensions and see what comes out? ] - Register the new provided conversions using babl_conversion_new(). [ What are linear, plane, planar ? ] - Default data type of components is 'double'. Others can be registered using babl_format_new(). - Specifying additional formats with babl_format_new() doesn't mean you have to provide conversions for those. You can leave it to babl to find a way. [ Or maybe not? naive-CMYK registers a CMYK float format without defining any conversions. BablFishPath.html shows that format w/o any conversions to or from it. ] - The components of one format don't all have to have the same data type. - New data types (e.g. integer with certain ranges) can be added using babl_type_new(). That's it for now. Regards Rupert ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
