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

Re: [E-devel] Premultiply or not

	Jose writes:

> > 
> > 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.
	I should add that this is also one reason why we want to
work entirely in premul color space - so we don't have to premul
anything, we just assume the inputs to be so and simply use them
as given.
	If one instead assumes the inputs to be non-premul, then
one has to, at the compositing stage, premultiply them -- what you
input is not really what gets used for compositing.


	Carsten writes:

> well actually i was thinking ALL engines would use premul ARGB
> by DEFAULT unless you tell them that you want to get/set pixel
> data in another colorspace (yuv, yuva (planar, interleaved etc.),
> non-premul argb etc. etc.). IF the engine CAN handle the format
> natively (eg some yuv formats if we have xvideo accel) then the
> engine will avoid any conversion internally and deal with it as-is.
> if it cannot - then it will convert as needed internally.

	What engine is going to "handle" non-premul argb "natively"?
That's what evas' software engines do right now, and creates the
inconsistency with the render engine.
	You can't perform transforms in non-premul color space and
expect to obtain the same results as similar transforms in premul
color space.

	You are mixing two different kinds of things here - yuv vs rgb
is NOT the same thing as premul vs non-premul.