[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 "firstname.lastname@example.org" <email@example.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
> 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....?
> 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
> enlightenment-devel mailing list
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) firstname.lastname@example.org
Tokyo, Japan (東京 日本)