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
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
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
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
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.
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
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
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
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()
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
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
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
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
13 matches
Mail list logo
