Re: possble replacement(s) for Gimp Lanczos

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux