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

Re: [E-devel] Premultiply or not

On Sun, 2 Jul 2006 23:57:15 GMT "jose_ogp@juno.com" <jose_ogp@juno.com> babbled:

> > 
> > 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..

agreed - with possible FUTURE ability to use more esoteric colorspaces like YUV
(though frankly yuv is handled most sanley by a convert to yuv first - BUT you
can actually get speedups combining the scale and convert at the same time)

> 	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.

sure - and i would suggest we expand it to also import non-premul ARGB - thats
basically all i was really suggesting. :)

> 	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.

oooh no - for me it means that became the api with which u dealt with evas.
evas internally would do whatever it damn well pleased. :) the only guarantee u
had is that u could present data in format X and get it back in format X. what
happend later was entirely out of scope and goign to happen in premul ARGB.

> 	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?

every edje design (.edc's) that specifies a color for text or solids, clips
etc. any app that sets an object color itself.  there are 74 calls to
evas_object_color_set in e17. e17's creation of netwm icons would need to do a
premul step. 54 in edje. more in ewl, etk etc. etc. now with edje - do we force
the .edc's to specify colors in premul? if so there are (evil) 666 instances of
colors in e17's default theme - or do we have edje_cc convert to premul on
encode - or do we have edje turn into premul runtime?... how far do you go? :)

> 	What about entrance, ewl/etk, etc....?
>    jose.
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)