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

Re: [E-devel] Premultiply or not



> > With the added stipulation that the data returned may not be
> > exactly the data given (due to colorspaces not mapping 1-1 on
> > each other). Unless you plan on keeping the untouched data around
> > somewhere (which would double the memory usage).
> 
> correct. non-premul to premul is destructive. VISUALLY it will look
> the same when composited, BUT this should be an understanding -
> correct.
> 

	Yes, that's right. It destroys the superflous information
that may be contained in the overdetermined inputs - as far as the
actual compositing is concerned.

	In every situation when compositing is involved, premul
colors are the way to go, and when it's desired to have a separate
means to control 'alphas', then a separate alpha-mask is the way
to do it.
	A similar mechanism should be used for all color+geometry
related aspects -- eg. as Keith Packard suggested, separate alpha-
stops for gradients, and I would do similarly for setting colored
vertices for paths, etc.
	It's either that, or the 'geometry' needs to be further
subdivided.
	In the 0-dim case of just a single 'multiplier' color in
isolation, giving a separate alpha value would be superflous, so
might as well let the color be premul to begin with.

	All the "holy specs" of svg, pdf, etc. (and maybe even
OpenGl), who believed that giving non-premul color data for
'vertices' as a means to allow for interpolation that would
otherwise be difficult or impossible with premul color inputs...
have screwed up, and are taking everyone else along for the ride.


   jose.