On Tue, Aug 24, 2010 at 9:58 AM, Rupert Weber <g...@leguanease.org> wrote:
> On 08/24/2010 04:20 AM, David Gowers wrote:
>> I hope you're not associating the quite suboptimal way in which GIMP
>> currently uses GEGL, with BABL's speed or lack of speed.
>> BABL just processes raw pixel buffers. A converter function just
>> accepts a source and a destination pointer, along with a pixel count,
>> and should convert that number of pixels. It doesn't have any heavy
>> architecture or processing, aside from what may be in each individual
>> converter function
>> looking at your code in gimpcolorspace.c, making that code work with
>> BABL looks like it's pretty much a case of cut+paste, modify the way
>> the input is referred to, add some registration code.
>> (getting your layer mode code to USE that, is a different issue, and I
>> agree that would be non-trivial, although you might get significant
>> speed gains from it because of greatly reduced function call overhead
>> -- probably about as much as you describe for inlining below.)
> As I indicated, I'll be happy to make the babl integration of those
> conversions my next little project, but I also expect a bunch of
> questions to come up in the process (color management comes to mind).
Color management does not have much to do with this, since the pixels
are already assumed to be in a well defined pixel format and color
space. Babl is nothing more than a collection of conversion functions,
meta data about the color spaces and data types used and the ability
to assess the conversion speed and quality of these conversions at
runtime. Thus as long as the claim as to what pixel format a buffer is
in is correct, use of babl is correctly color managed.
«The future is already here. It's just not very evenly distributed»
-- William Gibson
Gimp-developer mailing list