On Thu, Aug 27, 2020 at 11:58 PM Marti Maria <marti.maria@xxxxxxxxxxxxx> wrote: > This is Marti Maria, LittleCMS author. LittleCMS is the library you are using for color management. > > Couple of days go, a friend of mine bring my attention on a comment in GIMP release notes: > > "GIMP now uses LittleCMS v2, which allows it to use ICC v4 color profiles. It also partially relies on the babl library for handling color transforms, since babl is simply up to 10 times faster than LCMS2 for the cases we tested both of them on. Eventually babl could replace LittleCMS in GIMP.” > > Ouch, this like saying lcms2 is such slow that is inoperant and that babl guys can do it way better. Ok, that’s fine for me if true, but then I would like to apply the Sagan aphorism: "extraordinary claims require extraordinary evidence” > > So I have done some testing and created this entry on lcms2 website: > > http://littlecms.com/blog/2019/10/02/througput-babl/ <http://littlecms.com/blog/2019/10/02/througput-babl/> > > Which basically proves that the claim is not true and that lcms2 is clearly faster that babl on most operations. And for those very few cases, like floating point, that is not such fast, you have a plug-in under GPL3 that makes lcms2 shine in throughput and go way faster than babl. When babl started doing some of its own ICC handling lcms2's performance enhancing plug-ins were not publicly available and could be presumed to only be proprietarly license, while patches to make the non plug-in code paths of lcms2 faster have been rejected or discouraged, making lcms2 a pay-for-performance variant of open-core; which is hard to optimize for a downstream project. The availability of performant lcms2 under a free software license is good news; since then lcms2 is no longer pay-for-performance for programs that can use GPL3. The native representation for implementation of processing operations in GEGL and thus intermediate results in modern GIMP is 32bit floating point, floating point code for image handling is thankfully no longer an exception and rare but is starting to trend toward the rule in newly written code. Even when working on 8bit JPEGs you will get better results (fidelity as well as performance) by upgrading the image to floating point, even without such change lcms2 without extra performance enhancing plug-ins dominates profiles done for performance. for instance 32bit floating point to 8bit integer can be seen as crucial for display performance. > I would not enter on the question of the very limited subset of profiles that babl supports, the issue is the complex architecture you are forced to use (detect if a profile is suitable and then make color transforms take a different path) because the claim lcms2 is slow. And this claim, in my tests which you are welcome to review, is not true. babl is modular - and also contains performance (and functionality) enhancing plug-ins called extensions, these are however installed by default and under the same license as babl itself (LGPLv3+) and installed by default, new such extensions or additions to the existing ones are informed by bottlenecks observed in profiling GIMP and other programs using babl/GEGL. For the nascent CMYK capabilties in GEGL (which GIMP hopefully makes use of in the future 3.x series), babl is used for enumerating pixel formats and spaces like all other pixel formats but conversions are done with lcms2, the availability of performance enhancing plug-ins is good news, and I hope these plug-ins get packaged by distros and can be enabled by the code in GEGL that enables GPL code paths (most of GEGL is LGPLv3+, but some parts are GPL and should only be used by GPL abiding programs). /pippin _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
