Re: [Gegl-developer] babl docs
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 -- My GIMP Blog: http://www.chromecode.com/ "Automatic tab style and removed tab title bar" ___ Gegl-developer mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
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 [email protected] 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 [email protected] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
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 -- My GIMP Blog: http://www.chromecode.com/ "Automatic tab style and removed tab title bar" ___ Gegl-developer mailing list [email protected] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
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. ___ Gegl-developer mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 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 [email protected] 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
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
[email protected]
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
[email protected]
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 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
[email protected]
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
[email protected]
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 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 [email protected] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
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'? 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) Thanks Rupert ___ Gegl-developer mailing list [email protected] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On 09/09/2010 04:51 PM, Øyvind Kolås wrote: > 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... He, we'll see. If the trickery involves fried chicken... > 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. Yes, the idea was not to either quote the whole thing or take the questions out of context, but that leaves the answers ... out of context. ;/ (but I did add little numbers for reference) Maybe I should do it the other way around, and put some sort of tag/number in the document, so it's easy to find the spot the question is about. Thank you for all the answers. > packed/interleaved/chunky I'll just pretend I didn't read that, until I see how to do that without just bluntly tricking babl. ;) Regards Rupert ___ Gegl-developer mailing list [email protected] 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 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] babl docs
On 09/01/2010 10:08 AM, David Gowers wrote: > > Sounds like a great idea! Good. ;) And thank you for helping. >> [ 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) ) > [...] > * AFAICS, 'luma' is meant in a loose sense here.."this channel encodes > brightness in some sense" not "this channel encodes X specification of > brightness" I also understand those as a hint to babl as to what kind of information the component encodes. But it rather seems to be reserved for future babl magic? >> [ 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. If you supply a conversion, you'll have to be sure the respective models exist in babl. My assumption was that either you know they do, because they are part of 'core babl' (like RGBA), or you should make sure by registering it yourself. Relying on another extension to have registered the model doesn't seem stable. (What if that other extension is not loaded first, or removed altogether?). [ but see below ] > As far as I can see, you probably only want to: > [...] > 3. (no need to register new models or components) > I would have expected that I do have to register Lab/LCH models (of course not creating conflicts by registering them differently) because so far they are only registered by another extension. -- 'have to' meaning 'in order to play nice' as it would probably work to just let the other extension register them. Unless of course I do not regard the new conversions as separate/parallel to the existing, but rather an add-on to the existing Lab conversions. -- I didn't see it that way yet. In that case, it might also be right to add the new source to the current lib. (I.e. in Makefile.am, only add the source to an existing lib -- not create a new lib) Rupert ___ Gegl-developer mailing list [email protected] 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 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
[email protected]
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
