On 08/22/2010 02:45 PM, Sven Neumann wrote:
> New code in GIMP should use babl for pixel format conversion. There's no
> need to introduce new API for that as we have babl which is available to
> the core and plug-ins and provides a much superior API.

The short answer is: No. I won't do that.
For the long answer see further down below. (Sorry if this post becomes 
a bit longish)

First about the current state of affairs:
I posted the last update to the patch to

 From my point of view, it is now done.

Some performance numbers, comparing redraw times of legacy modes to the 
new LCH modes and to current GEGL LCH modes:
(Tested with a very large picture to get measurable numbers; still these 
are ca. numbers, obtained with a stop watch)

Mode         | Legacy | New LCH | GEGL/babl
Hue          |  3.6   |   6.4   |   396
Saturation   |  4.6   |   6.2   |   405
Color        |  4.7   |   4.1   |   431
Value/Lightn.|  3.5   |   4.1   |   416

So I'm in the ball park of the legacy modes, Color is even a little 
faster. Compared to current GEGL/babl the new modes are about 60 to 100 
times faster. (Yes, no typo)

As to accuracy, these are the round-trip pixel errors for Lab and LCH 
Error after round-trip [in 8bit RGB space]:
  L*a*b*                          L*C*H*
  0:   16561783 (  98.716%)      0:   16527659 (  98.513%)
  1:     214941 (   1.281%)      1:     248244 (   1.480%)
  2:        492 (   0.003%)      2:       1313 (   0.008%)
  3:          0 (   0.000%)       3:          0 (   0.000%)

The worst we get are off-by-two errors. You won't notice without 
diff'ing two layers.
If you don't just stack no-op layers on top of each other, out-of-gamut 
errors will be *far* greater than these.

So, as I already said, I consider the patch done now.

Things I will still be glad to change:
- Location/name of new file, name of exported functions, etc.
- Any bug fixes, of course.
- The open issues I had mentioned earlier (file formats,

Things I won't change:
- Optimization. I currently see no further optimization potential
   without uglifying the code.
   - As to putting the conversion outside the loop: Yes it can be done,
     but even if it is done, it doesn't belong in this patch.
     The current implementation in gimp_composite_generic.c is symmetric
     to the existing layer modes. So any such un-looping would be a
     general change to that file, not specific to the new layer modes.
   - Inlining: Brutally inlining everything can be done and gives some
     12%-15% performance increase. -- But I don't want to get my hands
     dirty with that.. :o)

And then there is babl.
I feel very bad about that request. Because I expect it to be the first 
step in a relatively short sequence of if-we-do-that-why-don't-we's that 
will end with these modes not getting in but rather be added to the GEGL 
As that is effectively what you are asking me to do: work on the GEGL 
modes instead (or duplicate them, which would be even sillier).
But that is not what I signed up for. The idea was to get something done 
and usable now. Not something that will be great in some uncertain future.

When this is done I will be glad to take a look at babl and see if the 
conversions can somehow be integrated. But I don't expect that to be a 
trivial task.

The patch is here. Now, and it works. The conversions add 17k of code. 
Once GEGL takes over, they'll simply removed again. No one gets hurt.



Gimp-developer mailing list

Reply via email to