[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Premultiply or not
On Sun, 2 Jul 2006 08:25:04 GMT "email@example.com" <firstname.lastname@example.org> babbled:
> Carsten writes:
> > 1. ......
> > 5 .......
> The troubles of having evas' software engine do transforms
> in premul color space whereas the render engine does so in premul
> are only seen so far if you look carefully or try to do certain
> things.. But they are a very deep inconsistency and makes evas
> basically worthless for any serious consideration of these
> engines as more or less 'interchangeable'.
no - i was meaning allow at the evas API level to PROVIDE non-premul image
data. evas converts to premul internally like the xrender engine does - keeping
a private premul copy when needed. this is a convenience for programmers who
can't/dont handle premul in their app. the conversion routines are internal -
they are simply called when needed.
> > 6. the problem we have is for evas_color_set() and then edje
> > and nigh everything that depends on this. if we go premul for
> > this just about everything will break and need fixing. this is
> > a lot of stuff.
> Having edje pass premul colors to evas would be trivial.
> If that's all apps/libs are using then they wouldn't have to do
> a thing.
sure- but it's not just edje - a lot of apps, widget sets etc. then again if
everyone is willing to help port the workload can be reduced.
> > what i think might be best is we:
> > 1. add internal premul to non-premul and back conversion routines
> > (need them anyway - may as well make them fast).
> > 2. need to add calls to image objects to get/set the COLORSPACE
> > of the internal object data (the default would be premul and the
> > suggestion would be to leave it alone unless you have very special
> > needs).
> What good would that do for all but the software engines
> (and possibly the gl engine). You can't make render do transforms
> with data in non premul colorspace - one'd just be back to the
> situation that exists now except with two sets of compositing
> (and other drawing) routines in the software engine.
1. convenience for programmers/compatibility and the ability to extend it in
future to allwo DIRECT YUV access for example for emotion - and then the ENGINE
has to deal with conversion, not evas. if the engine can deal with yuv directly
- then it will do it natively (eg use xvideo or YUV gl textures etc.). right
now this is a big problem as we can't make use of any acceleration of yuv->rgb.
admittedly xvideo sucks right now as it basically will not (in almost all
cases) be able to write/composite xvideo yuv data TO a pixmap - BUt this is set
to change - as the word in from keithp etc. is - when drivers catch up etc. we
should just be ready for the day it happens and then simply hook up the right
routines, but until that day, do out own yuv->rgb conversion, but at the
engine, not the evas level.
> > 3. move default colorspace to ARGB_PREMUL (we can have non-premul
> > space, but it will need conversion to premul before using in
> > routines).
> What is the point of having a color space that you can't
> do gfx with internally except convert it to premul?
> Only if all the evas engines could work with both premul
> and non premul color space in their gfx handling routines would
> this make any sense.. and it would still be highly suspect to
> be able to use this coherently.
as an input format only. it gets converted when needed into the native format.
you agreed providing routines to go to/from premul is good - if u are providing
them- how are u going to USE them? i wasn't thinking of exposing them to apps
at the evas api level - only as internal calls that convert the data presented
to the app as the image pixel data.
> > 4. i think the best might be we have a evas_colorspace_set(evas,
> > EVAS_COLORSPACE_ARGB_PREMUL); for example and a EVAS_COLORSPACE_ARGB
> > and that leads to EVAS_COLORSPACE_YUVA as well so then evas can do
> > the conversion (if needed) when setting the color of an object on
> > that canvas. this will mean we can port existing code with 1 function
> > call when creating the canvas (set it to the non premul argb).
> > perhaps also per object too (an objects specific colorspace overrides
> > the evas one).
> What's the point of having this in the canvas when such
> color spaces can't be used directly in a coherent way?
evas does the conversion to an internal native format as needed (premul argb).
otherwise we will be moving that conversion outside of evas - that would be
the "big fat port" to premul.
> You already have the YUV import call, and what does it
> do? Convert to rgb since there's no internal support by any
> of the engines to composite ayuv with argb. Not only that, but
> there are questions of coherence when it comes to using transforms
> that are not easily dealt -- just as now you have two different
> results from scaling data with the software vs the render engines
> when the results are rendered. Are you prepared to do scaling/shearing
> etc. in ayuv space prior to compositing - how will you have render
> do this right now? Have you thought out the results of what this
> will lead to vs first converting to rgb and then scaling/shearing..?
> Which one(s) you want and why?
yes - i would actualyl consider doing the transforms in yuv space IF that was a
better/faster path. i'd personally in the hw accel engines let the hw do it -
in yuv space using "xvideo" or "yuv textures" and thus the need to export
colorspace to the apps so they can provide the pixels in the most appropriate
colorspace (for video, yuv for example). if needed the data will be converted
then composited, or if possible done natively all the way through (ev yuv
textures/xvideo works with writing video to pixmaps).
> This is why I didn't want to add eg. an api func for
> adding ahsv colors to grads, and instead had the interpolation
> happen there.. I could imagine setting such an interpolation
> color space to be premul argb/ayuv, non premul argb/ayuv, etc.
> But there needs to be good reason.. and even more for having other
> color-space *entry* points. That colors can come in different
> color spaces alone is not good enough reason - conversion funcs
> are for that.
> > then we can begin a migration of code over to premul and remove
> > the call - but still keep it there for the ability to switch into
> > a more convenient colorspace. i am not sure this colorspace should
> > affect image pixels though... that should be per image object as
> > above.
> It all sounds very nice... set the color space as you wish,
> per object even.. :) But it's not so nice when you look deeper.
> I would consider some of this to be partially viable
> only when the main engines you want to use (software and render)
> are capable of dealing with transforms and compositing in these
> color spaces.. Otherwise it's nothing but an inconsistent mess.
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
> 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) email@example.com
Tokyo, Japan (東京 日本)