[Gegl-developer] babl: Floating point suffix
Hi, Many floating point constants in babl are suffixed with an 'F', even though they are used (i.e. converted soon thereafter) as doubles. (And again recently on GIMP with the Megapixel-patch). While my reflex would be to just change that whenever I come across it, I first wanted to make sure there isn't some rationale behind it that I'm not seeing. Is there? 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 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 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 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 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
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
[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