On Thu, Aug 21, 2008 at 3:01 PM, Nicolas Robidoux <nrobidoux@xxxxxxxxxxxxxxxx> wrote: > David Gowers has suggested using LittleCMS (or GeGL) to linearize colour profiles during the computation. In our experience, our plug-ins produce good results when used in a "gamma OBLIVIOUS way." This being said, back of the envelope computations suggest that "light" haloing is likely to decrease if the colour profile is properly taken into account (because sRGB has a linear component near black, "dark" haloing is probably not going to change much for such images; again, this is from a very rough back of the envelope reasoning). Given that GeGL will perform all the heavy lifting for the Gimp in the future, I am not sure that fixing the gamma correction at this point is really something I want to do. However, I will try to integrate profile information in the profile if it is felt that it is important. > > The current "gamma" versions of the plug-ins use "naive" gamma correction (and do not take into account the linear piece of sRGB). David's plan is a much better one. A summary of image resampling in GEGL: GEGL is being designed to operate correctly on images, the current samplers operate on "RaGaBaA float" buffers, which is the babl notation for premultiplied alpha linear light RGB with opacity. This causes a resampling and resumming of the buffer behaving like phyiscal light, ray tracing and compositing operations are other operations that give the most correct result when operated upon in linear light. http://www.4p8.com/eric.brasseur/gamma.html details some of the problems with correcting sRGB data directly. Sampling types in GEGL are subclasses of a generic base class providing a a cache. This is less efficient than having the different samplers directly in the scaling code, but allows reusing them for all affine transformations, displacement maps, iwarp or other similar image deformations. Fast paths for scaling with specific samplers could probably be added later and tested against the generic extendable sampler framework for correctness at a later point. The cache that is used is a 64x64 linear circular buffer guaranteed to contain the entire needed spatial context of pixels. To see how the current samplers are implemented see: http://svn.gnome.org/viewvc/gegl/trunk/gegl/buffer/gegl-sampler-linear.c?revision=2489&view=markup Currently nearest, linear, cubic and lanczos scalers have been implemented. Scaling down is currently not handled correctly by the implementation, but for equal scaling on both x and y axis the sampling API should be sufficient to express the needs. /Ø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