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

Re: [E-devel] Premultiply or not



> 
> we need the ability to have image objects in different
> colrospaces yugv(and its variants, yuv422, yuv420, etc. etc.)
> is a long-term must. the ENGINE has to deal with yuv data.
> if it can't it can always use the yuv import calls internally
> to RGBA then do it all in RGBA land - but if the subsyetm
> (gl/xrender/etc.) can do yuv natively - then do it that way,
> hoping the hw accel does a much better job than we do. adding
> in ARGB non-premul as another colorspace is merely convenience
> as its just the SAME logic as handling a yuv image object - 
> having to convert to a native format before using it. in fact
> its probably the thing we would want to test with to start with.
> yuv would get support later.
> 

	Let's agree on one thing:  The gfx operations, unless
otherwise explicitly stated, will be done in premul argb color
space, or a linear equivalent of it..

	Ok, fine.. and actually premul ayuv would be ok too since
when decoded yuv is linearly related to rgb (hsv eg. is not).
There's already such an interface to set imported data from yuv,
and moving the 'conversion' to rgb down to the engines is fine
as they may simply be able to deal with it directly, etc..
That's all good, and an interface for importing yuv to image data
is already there, you can extend it to cover any premul ayuv format
type with no problem.

	But, "setting" a color space, either globally or per obj,
has only one real meaning - that the color space in question is
going to be used as the current context for gfx ops.
	Doing this for non premul anything, is shear folly. Any
'benefit' you claim can be obtained for apps/libs that want to
deal with non-premul color spaces by deferring premultiplying
till it may be needed and whatnot.. is microscopic compared to the
confusion, complexity, etc. caused by this misrepresentation.

	Now, you can argue that maybe not "setting", but rather
"importing", non-premul color space formats for conversion is ok..
But I don't see anything worthwhile in providing such interfaces
for data and/or colors, and just see an increase in complexity
in dealing with that internally and, again, microscopic gains.

	Let's assume that edje has been modified to pass premul
colors/data to evas, and eet saves premul data, and that evas
provides premul/non-premul conversion api functions for colors
data..

	Just where exactly in e17 would there be even minor pain
caused by evas being premul only?

	What about entrance, ewl/etk, etc....?


   jose.