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
        http://bugzilla.gnome.org/attachment.cgi?bugid=325564

 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 
conversions:
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,
   GIMP_COMPOSITE_BLEND et al.)

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 
agenda.
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.

Regards

Rupert













_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to