On Sat, Sep 11, 2010 at 1:21 PM, Rupert Weber <gimp@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
