I was looking into etk/ewl code and i saw that they are using evas_object_image_data_get in some places and they are assuming that the data is always in RGBA8888 format (as it was before). Probably other projects (modules) do the same. Maybe some helper functions in evas to retrieve the rgba components of an evas_object_image would be helpful.
BR Andrunko On 7/10/07, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > On 7/10/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > > On 7/10/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > > > On 7/9/07, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > On 7/9/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > > > > > On 7/9/07, Andre Magalhaes <[EMAIL PROTECTED]> wrote: > > > > > > Hey Raster, > > > > > > > > > > > > On 7/9/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > > > > > > On Fri, 6 Jul 2007 18:00:08 -0300 "Andre Magalhaes" <[EMAIL > > > > > > > PROTECTED]> > > > > > + o->engine_data = > > > > > obj->layer->evas->engine.func->image_data_get(obj->layer->evas->engine.data.output, > > > > > + > > > > > o->engine_data, > > > > > + 0, > > > > > + > > > > > &data); > > > > > + data += (y * w) + x; > > > > > + a = (*data >> 24) & 0xff; > > > > > > > > > > this will not work for engines != 32bpp, like my 16bpp. If not > > > > > existent, we need to write an engine-provided get_pixel(), that give > > > > > normalized 0-255 components. > > > > I imagined that but in the documentation of evas_object_image_data_get > > > > it says: > > > > * @return A pointer to the raw data as 32 bit unsigned integer in > > > > format ARGB. > > > > I thought that all engines should convert it to 32 bits in this case, > > > > as it's stated on documentation. I am using the same method as > > > > evas_object_image_data_get uses. Please someone could clarify this. > > > > > > Hum... I need to update this doc since it's not true anymore (since > > > 16bpp engine, the first non-32bpp), maybe also providing engine > > > functions to manipulate this data. > > > > > > It's a no-go to convert image buffers to 32bpp for these operations, > > > some images would take a lot of CPU and memory (800x600 = 480,000 > > > iterations, 1440,000 bytes, to access one value of interest (alpha). > > > > talking to andré in private and also reading recent commits by raster > > about colorspace, we have noticed that is still impossible to get the > > pixel with available info, since buffer is not based on just width and > > height, but also on row stride, this is used (at least in 16bpp) to > > provide better alignment. > > I've fixed the evas patch to take into account the has_alpha value of > the image and also the colorspace. For now i am using width instead of > stride (i know it's wrong), so we need to decide whether to have a > get_pixel on the engine or export the stride attr to > Evas_Object_Image. > > I've also fixed the coding styles parentheses issue :D > > BR > Andrunko > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
