On Tue, Aug 24, 2010 at 1:52 AM, Rupert Weber <gimp@xxxxxxxxxxxxxx> wrote: > 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) Due to the hacky way it is implemented, to enable using the GEGL code paths alongside the legacy code paths without breaking the legacy code paths. Additional conversions back and forth between 8bit and 32bit float are needed, and the processing is not done in non-optimal amounts. > 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. Such an error should be unacceptable, the conversion code for CIE Lab in babl are symmetric. > So, as I already said, I consider the patch done now. > 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. I suspect that the code is already triply duplicated now then, the original GIMP CIE Lab code in app/base/cpercep.c , it's copy in babl/ectensions/CIE.c and your conversion code. If you add your conversion code to babl as well it will be picked instead of the existing conversion, if it is both symmetric and faster than the existing implementations. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ ; http://ffii.org/ _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
