Only 0-255 levels of alpha channel

> only you don ' T see it, because the> color_alpha->calculate > function just always returns *covers. In my case, I>  was using> a combined alpha  (Source x shape) ... Ah, i see. well, the division by 255 is too expensive. the usual technique there is to add 128 to theintermediate  result:v +  (((r - v)  * alpha + 0x80)  >> 8); BUT IT ALSO REQUIRES THE ALPHA TO BE IN RANGE 0...256 (not  255),  so that it ' s not an easy issue, because iuse  0...255. besides, sometimes i use precalculatedalpha in range 0...255* 255.the very same issue is applicaBle to the calculationof the color_alpha->calculate (). Anyway, you can try to play with these formulas andi ' d  Appreciate if someone could help me to systematizethese things.

> The problem is with the bilinear filter. I implemented>  it separately from the general arbitrary filtering> algorithm  because it works about 40% faster. but if> you take  the  "Image_filters"  example and play with it> you will  See that the bilinear filter darkenes the> image. well, the image_filters example would have the same problemi  Witnessed in my case; pixel_formats_rgb24_image::span doesthe same kind  of shifting, i guess. Only you don ' t see it, because the color_alpha->calculatefunction  just always returns *covers. in my case, i was usinga  Combined alpha  (Source x shape) ... 

well, the problem is even worse than just  "Speed up" (BTW, it &NBSP;DOESN ' t matter much because the most timeconsuming code is  Interpolation itself) the problem is with the bilinear filter. i  implementedit separately from the general arbitrary filteringalgorithm  because it works about 40% faster. but ifyou take the  "image _filters " example and play with ityou will see that the  bilinear filter darkenes theimage. then if you comment out  "case  1 "/*        case 1:             {                 typedefagg::image_transform_attr<agg::null_distortions,                                                     agg::null_color_alpha,                                                     agg::null_gradient_alpha> attr_type;                 typedefagg::span_null_interpolator<attr_ type>span_interpolator;                 typedef

Agg::p ixfmt_bgr24_image_bilinear<attr_type>span_renderer;                 typedefagg::renderer_scanline<span_interpolator,span_ renderer> renderer;                 agg::null_distortions    distortions;                  agg::null_color_alpha     color_alpha;                 agg::null_gradient_alphagradient_alpha;                 attr_type attr (rbuf_img (1), img_mtx,distortions,  Color_alpha, gradient_alpha);                 renderer ri (rbuf_img (0));                 Ri.attribute (attr);                 ras.add_path (TR);                 ras.render (RI);            }             break;*/

 Nd uncomment // case 1: below, the bilinearinterpolation will  be done through the general method. In this case everything is fine. i honestly don ' t knowwhy,  But there ' s something wrong with rounding off,that is, the  probability of rounding to the floor ishigher than to the  ceiling. perhaps i should use thearray of the precalculated  Weights rather than computethem on demand. 

i have been playing with the image transform classes,  specificallywith the code in agg_pixfmt_rgba32_image.h, and i have  Noticed afew problems with the code you are using to handle  the alpha values. There are often places where you multiply values ranging from  0 to255, but then, finally, divide them by 256  (>>  8). Here is an example of what i have observed. In method agg::p Ixel_formats_rgba32_image_bilinear::span, using classagg::image_alpha_ Rgba8 as an alpha provider, if i step through thecode, i  see that :- image_subpixel_mask = 0xff- weight = 0xfe01- fg [3]  = 0XFe02ff  (SOURCE ALPHA WAS 0XFF) after fg[3] >>= image_subpixel_shift  * 2,- fg[3]  = 0xfe;  // should be 0xff if  divided by 0xff*0xff- alpha is the calculated on this base :     0xff * 0xfe => 0xfd02    0xfd02 > > 8 => 0xfd

So I end to with alpha = 253 rather than 255, and all the nicespeed-up code (alpha = = 255) doesn ' t get executed, and somen Oise gets added to the output. Any idea how to fix the this on an elegant-in-A-Z (I could just decreasethe threshold for which alpha is considered 100% opaque) ?

Only 0-255 levels of alpha channel