|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
|
|
Blending and Drawing produce different image..Here is situation.. 1. Draw rectangle A with Solid Color RGBA(0,0,255,128) 2. Draw rectangle B with solid color RGBA(0,255,0,128) overlapped with A 3. Draw rectangle C -RGBA(0,255,0,128) in different DIB buffer and blend over rectangle A all pixel format was agg::pixfmt_bgra32 overllapped area between 1 and 2, 1 and 3 produce different color :(.. How can I fix this problem..?? ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..It's not bug. It's your understanding problem.
If you want to get the same color. Blend B and C first.
On Sun, Feb 15, 2009 at 7:50 AM, Peter Yang <magingax@...> wrote:
------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..To describe simplify my problem..
Rectangle B is just 'drawn' to buffer.. Rectangle C is drawn to different small buffer and 'Blended' to buffer - copy small buffer to buffer At this point color of these two rectangle is different even initial drawing color were same... I think there are some different algorithm between 'drawing' and 'blending' ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..Could the different results be caused by using plain or premultiplied
color formats? Dirretent in each case. Br, Vlasta On Mon, Feb 16, 2009 at 1:04 AM, Peter Yang <magingax@...> wrote: > To describe simplify my problem.. > > Rectangle B is just 'drawn' to buffer.. > Rectangle C is drawn to different small buffer > and 'Blended' to buffer - copy small buffer to buffer > > At this point color of these two rectangle is different even > initial drawing color were same... > > I think there are some different algorithm > between 'drawing' and 'blending' > > > > > > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Vector-agg-general mailing list > Vector-agg-general@... > https://lists.sourceforge.net/lists/listinfo/vector-agg-general > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..Peter Yang wrote:
> Here is situation.. > > 1. Draw rectangle A with Solid Color RGBA(0,0,255,128) > 2. Draw rectangle B with solid color RGBA(0,255,0,128) overlapped > with A > 3. Draw rectangle C -RGBA(0,255,0,128) in different DIB buffer > and blend over rectangle A > > all pixel format was agg::pixfmt_bgra32 > > overllapped area between 1 and 2, 1 and 3 produce different color :(.. This is because your buffers are premultiplied, i.e. for each pixel the RGB values are scaled by the alpha value. pixfmt_bgra32 blends "plain" (non-premultiplied) source with premultiplied destination. pixfmt_bgra32_pre blends premultiplied source with premultiplied destination. pixfmt_bgra32_plain blends plain source with plain destination. Therefore, to blend two premultiplied buffers you need to use pixfmt_bgra32_pre. - Jim ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Using pattern fill with a rgb555 pixel formatHi everyone.
When I try the example called "pattern_fill" with the pixel format AGG_RGB555 (by uncommenting this macro in the beginning of the pattern_fill.cpp file), I can't compile it. In fact, the problem is that the class "pixfmt_alpha_blend_rgb_packed" has a so called fake order_type. So my question is the following : Can we use images as fill patterns if we use pixel format that are not defined as 32 bits ? Thanks. Stephane. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Using pattern fill with a rgb555 pixel formatStéphane CHAU wrote:
> Hi everyone. Hi Stéphane. When asking a question, please start a new thread rather than replying to an existing message. > When I try the example called "pattern_fill" with the pixel format > AGG_RGB555 (by uncommenting this macro in the beginning of the > pattern_fill.cpp file), I can't compile it. > In fact, the problem is that the class "pixfmt_alpha_blend_rgb_packed" > has a so called fake order_type. Yes, span_pattern_rgba only supports unpacked RGBA sources so you'd have to implement your own variant to handle packed formats. However, you can still fill a packed-format destination, as long as the source is unpacked. - Jim ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Using pattern fill with a rgb555 pixel formatStéphane CHAU wrote:
> Can we use images as fill patterns if we use pixel format that are not > defined as 32 bits ? Just off the top of my head, you could copy and rename span_pattern_rgba to span_pattern_rgb555, and change the "generate" method to something like this: void generate(color_type* span, int x, int y, unsigned len) { typedef source_type::pixfmt_type::pixel_type pixel_type; x += m_offset_x; y += m_offset_y; const pixel_type* p = (const pixel_type*)m_src->span(x, y, len); do { color_type c = agg::blender_rgb555::make_color(*p); span->r = c.r; span->g = c.g; span->b = c.b; span->a = c.a; p = (const pixel_type*)m_src->next_x(); ++span; } while(--len); } ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Using pattern fill with a rgb555 pixel formatJim Barry wrote:
> void generate(color_type* span, int x, int y, unsigned len) > { > typedef source_type::pixfmt_type::pixel_type pixel_type; > x += m_offset_x; > y += m_offset_y; > const pixel_type* p = (const pixel_type*)m_src->span(x, y, > len); > do > { > color_type c = agg::blender_rgb555::make_color(*p); > span->r = c.r; > span->g = c.g; > span->b = c.b; > span->a = c.a; > p = (const pixel_type*)m_src->next_x(); > ++span; > } > while(--len); > } Or, somewhat more succinctly: void generate(color_type* span, int x, int y, unsigned len) { typedef source_type::pixfmt_type::pixel_type pixel_type; x += m_offset_x; y += m_offset_y; const pixel_type* p = (const pixel_type*)m_src->span(x, y, len); do { *span++ = agg::blender_rgb555::make_color(*p); p = (const pixel_type*)m_src->next_x(); } while(--len); } :-) ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..But premult pixel format has serious problem..
In this situation, destination format is pixfmt_rgba32_pre and source format is also pixfmt_rgba32_pre 1. Speed is too slow - there must be inefficient calc in premult format 2. When two object overlapped..overlapped area has unexpected color. How can I fix this ?? ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..Hi all,Here is situation.. 1. Draw rectangle A with Solid Color RGBA(0,0,255,128) 2. Draw rectangle B with solid color RGBA(0,255,0,128) overlapped with A 3. Draw rectangle C -RGBA(0,255,0,128) in different DIB buffer and blend over rectangle A all pixel format was agg::pixfmt_bgra32 overllapped area between 1 and 2, 1 and 3 produce different color :(.. How can I fix this problem..?? ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H on the same subject, I am a bit confused on the pre_mult, plain and bgra32 formats and blenders. In essence I have wrapper canvas classes which provide functionality on agg::pixmap of pxfmt_bgra32. When I try to blend two of these canvases using blend_from the only time I get acceptable (no artifacts) results is when both base pixmaps are of pixfmt_bgra32_plain. I also read that this is the slowest blender due to the division in there. So the question is simple, I have different canvas (with pixmap, buffer, render etc) which I wish to be able to blend with each other using blend_from(). What is the best way to achieve bgra32 to bgra32 blending? Here is some code to replicate the problem: typedef agg::pixfmt_bgra32 pixfmt; // if this is not set to pixfmt_bgra32_plain artifacts occur typedef agg::renderer_base<pixfmt> baseren; typedef agg::renderer_scanline_aa_solid<baseren> solidren; pixel_map pixmap1; pixel_map pixmap2; pixmap1.create(400, 400, org_e::org_color32, 0); pixmap2.create(400, 400, org_e::org_color32, 0); rendering_buffer mBuffer1( pixmap1.buf(), pixmap1.width(), pixmap1.height(), pixmap1.stride() ); rendering_buffer mBuffer2( pixmap2.buf(), pixmap2.width(), pixmap2.height(), pixmap2.stride() ); pixfmt pixfmt1(mBuffer1); pixfmt pixfmt2(mBuffer2); scanline_u8 sca1; scanline_u8 sca2; rasterizer_scanline_aa<> ras1; rasterizer_scanline_aa<> ras2; baseren baseRenderer1(pixfmt1); baseren baseRenderer2(pixfmt2); solidren ren1(baseRenderer1); solidren ren2(baseRenderer2); baseRenderer1.clear(rgba8(168,128,255)); baseRenderer2.clear(rgba8(0,0,0,0)); path_storage path; path.move_to(100.5,100.5); path.line_to(301.6,255.4); path.line_to(201.6,200.4); agg::conv_stroke<path_storage> stroke(path); stroke.width(5.0); stroke.line_join(line_join_e::round_join); ras2.reset(); ras2.add_path(stroke); ren2.color(rgba8(255,255,128)); // yellow render_scanlines(ras2, sca2, ren2); render_scanlines(ras1, sca1, ren1); baseRenderer1.blend_from(pixfmt2); pixmap1.save_as_bmp("c:\\temp.bmp"); ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..George schrieb:
> Peter Yang wrote: >> Here is situation.. >> >> 1. Draw rectangle A with Solid Color RGBA(0,0,255,128) >> 2. Draw rectangle B with solid color RGBA(0,255,0,128) overlapped with A >> 3. Draw rectangle C -RGBA(0,255,0,128) in different DIB buffer >> and blend over rectangle A >> >> all pixel format was agg::pixfmt_bgra32 >> >> overllapped area between 1 and 2, 1 and 3 produce different color :(.. >> >> How can I fix this problem..?? >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> > Hi all, > > on the same subject, I am a bit confused on the pre_mult, plain and > bgra32 formats and blenders. In essence I have wrapper canvas classes > which provide functionality on agg::pixmap of pxfmt_bgra32. When I try > to blend two of these canvases using blend_from the only time I get > acceptable (no artifacts) results is when both base pixmaps are of > pixfmt_bgra32_plain. I also read that this is the slowest blender due to > the division in there. > > So the question is simple, I have different canvas (with pixmap, buffer, > render etc) which I wish to be able to blend with each other using > blend_from(). What is the best way to achieve bgra32 to bgra32 blending? > > Here is some code to replicate the problem: > > typedef agg::pixfmt_bgra32 pixfmt; // if this typedef agg::pixfmt_bgra32_pre pixfmt; > is not set to pixfmt_bgra32_plain artifacts occur > typedef agg::renderer_base<pixfmt> > baseren; > typedef agg::renderer_scanline_aa_solid<baseren> > solidren; > > pixel_map pixmap1; > pixel_map pixmap2; > > pixmap1.create(400, 400, org_e::org_color32, 0); > pixmap2.create(400, 400, org_e::org_color32, 0); > > > rendering_buffer mBuffer1( pixmap1.buf(), > pixmap1.width(), pixmap1.height(), pixmap1.stride() ); > rendering_buffer mBuffer2( pixmap2.buf(), > pixmap2.width(), pixmap2.height(), pixmap2.stride() ); > > > pixfmt pixfmt1(mBuffer1); > pixfmt pixfmt2(mBuffer2); > > scanline_u8 sca1; > scanline_u8 sca2; > > rasterizer_scanline_aa<> ras1; > rasterizer_scanline_aa<> ras2; > > baseren baseRenderer1(pixfmt1); > baseren baseRenderer2(pixfmt2); > > solidren ren1(baseRenderer1); > solidren ren2(baseRenderer2); > > baseRenderer1.clear(rgba8(168,128,255)); > baseRenderer2.clear(rgba8(0,0,0,0)); baseRenderer1.clear(rgba8(168,128,255).premultiply()); baseRenderer2.clear(rgba8(0,0,0,0).premultiply()); // not necessary, since 0,0,0,0 is the same in non-pre and // pre-multiplied > > > path_storage path; > path.move_to(100.5,100.5); > path.line_to(301.6,255.4); > path.line_to(201.6,200.4); > > agg::conv_stroke<path_storage> stroke(path); > stroke.width(5.0); > stroke.line_join(line_join_e::round_join); > > ras2.reset(); > ras2.add_path(stroke); > > ren2.color(rgba8(255,255,128)); // yellow ren2.color(rgba8(255,255,128).premultiply()); // yellow > > render_scanlines(ras2, sca2, ren2); > render_scanlines(ras1, sca1, ren1); > > baseRenderer1.blend_from(pixfmt2); Depending on what your save_as_bmp() expects, you may have to use this before calling the function: pixfmt2.demultiply(); > pixmap1.save_as_bmp("c:\\temp.bmp"); Hope this helps & best regards, -Stephan ------------------------------------------------------------------------------ _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..Indeed it does and I think it is faster than using plain...
-----Original Message----- From: Stephan Aßmus [mailto:superstippi@...] Sent: Tuesday, March 10, 2009 1:08 AM To: Anti-Grain Geometry Subject: Re: [AGG] Blending and Drawing produce different image.. George schrieb: > Peter Yang wrote: >> Here is situation.. >> >> 1. Draw rectangle A with Solid Color RGBA(0,0,255,128) >> 2. Draw rectangle B with solid color RGBA(0,255,0,128) overlapped with A >> 3. Draw rectangle C -RGBA(0,255,0,128) in different DIB buffer >> and blend over rectangle A >> >> all pixel format was agg::pixfmt_bgra32 >> >> overllapped area between 1 and 2, 1 and 3 produce different color :(.. >> >> How can I fix this problem..?? >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> > Hi all, > > on the same subject, I am a bit confused on the pre_mult, plain and > bgra32 formats and blenders. In essence I have wrapper canvas classes > which provide functionality on agg::pixmap of pxfmt_bgra32. When I try > to blend two of these canvases using blend_from the only time I get > acceptable (no artifacts) results is when both base pixmaps are of > pixfmt_bgra32_plain. I also read that this is the slowest blender due to > the division in there. > > So the question is simple, I have different canvas (with pixmap, buffer, > render etc) which I wish to be able to blend with each other using > blend_from(). What is the best way to achieve bgra32 to bgra32 blending? > > Here is some code to replicate the problem: > > typedef agg::pixfmt_bgra32 pixfmt; // if this typedef agg::pixfmt_bgra32_pre pixfmt; > is not set to pixfmt_bgra32_plain artifacts occur > typedef agg::renderer_base<pixfmt> > baseren; > typedef agg::renderer_scanline_aa_solid<baseren> > solidren; > > pixel_map pixmap1; > pixel_map pixmap2; > > pixmap1.create(400, 400, org_e::org_color32, 0); > pixmap2.create(400, 400, org_e::org_color32, 0); > > > rendering_buffer mBuffer1( pixmap1.buf(), > pixmap1.width(), pixmap1.height(), pixmap1.stride() ); > rendering_buffer mBuffer2( pixmap2.buf(), > pixmap2.width(), pixmap2.height(), pixmap2.stride() ); > > > pixfmt pixfmt1(mBuffer1); > pixfmt pixfmt2(mBuffer2); > > scanline_u8 sca1; > scanline_u8 sca2; > > rasterizer_scanline_aa<> ras1; > rasterizer_scanline_aa<> ras2; > > baseren baseRenderer1(pixfmt1); > baseren baseRenderer2(pixfmt2); > > solidren ren1(baseRenderer1); > solidren ren2(baseRenderer2); > > baseRenderer1.clear(rgba8(168,128,255)); > baseRenderer2.clear(rgba8(0,0,0,0)); baseRenderer1.clear(rgba8(168,128,255).premultiply()); baseRenderer2.clear(rgba8(0,0,0,0).premultiply()); // not necessary, since 0,0,0,0 is the same in non-pre and // pre-multiplied > > > path_storage path; > path.move_to(100.5,100.5); > path.line_to(301.6,255.4); > path.line_to(201.6,200.4); > > agg::conv_stroke<path_storage> stroke(path); > stroke.width(5.0); > stroke.line_join(line_join_e::round_join); > > ras2.reset(); > ras2.add_path(stroke); > > ren2.color(rgba8(255,255,128)); // yellow ren2.color(rgba8(255,255,128).premultiply()); // yellow > > render_scanlines(ras2, sca2, ren2); > render_scanlines(ras1, sca1, ren1); > > baseRenderer1.blend_from(pixfmt2); Depending on what your save_as_bmp() expects, you may have to use this before calling the function: pixfmt2.demultiply(); > pixmap1.save_as_bmp("c:\\temp.bmp"); Hope this helps & best regards, -Stephan ------------------------------------------------------------------------------ _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general ------------------------------------------------------------------------------ _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..Stephan Aßmus schrieb:
[...] > Depending on what your save_as_bmp() expects, you may have to use this > before calling the function: > > pixfmt2.demultiply(); Make that: pixfmt1.demultiply(); >> pixmap1.save_as_bmp("c:\\temp.bmp"); Ciao, -Stephan ------------------------------------------------------------------------------ _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..Yeap, figured that much ;-)
-----Original Message----- From: Stephan Aßmus [mailto:superstippi@...] Sent: Tuesday, March 10, 2009 1:16 AM To: Anti-Grain Geometry Subject: Re: [AGG] Blending and Drawing produce different image.. Stephan Aßmus schrieb: [...] > Depending on what your save_as_bmp() expects, you may have to use this > before calling the function: > > pixfmt2.demultiply(); Make that: pixfmt1.demultiply(); >> pixmap1.save_as_bmp("c:\\temp.bmp"); Ciao, -Stephan ------------------------------------------------------------------------------ _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general ------------------------------------------------------------------------------ _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..George Vlahakis schrieb:
> Indeed it does and I think it is faster than using plain... Yes, it's faster. Also note that this is the only color space where you can properly perform filter operations like bilinear scaling with correct handling of alpha, or applying blur filters and so on. Best regards, -Stephan ------------------------------------------------------------------------------ _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..Stephan Aßmus wrote:
> baseRenderer1.clear(rgba8(168,128,255).premultiply()); > baseRenderer2.clear(rgba8(0,0,0,0).premultiply()); > // not necessary, since 0,0,0,0 is the same in non-pre and > // pre-multiplied And rgba8::premultiply() is a no-op when alpha is 255 :-) - Jim ------------------------------------------------------------------------------ _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..Stephan Aßmus wrote:
> Yes, it's faster. Also note that this is the only color space where > you can properly perform filter operations like bilinear scaling with > correct handling of alpha, or applying blur filters and so on. Well, it's possible to do properly in non-premultiplied space, though the calculations are more complex. But it's certainly true that the filters provided by AGG only work in premultiplied space. - Jim ------------------------------------------------------------------------------ _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..Jim Barry schrieb:
> Stephan Aßmus wrote: >> Yes, it's faster. Also note that this is the only color space where >> you can properly perform filter operations like bilinear scaling with >> correct handling of alpha, or applying blur filters and so on. > > Well, it's possible to do properly in non-premultiplied space, though the calculations are more complex. But it's certainly true that the filters provided by AGG only work in premultiplied space. I would respectfully disagree, since essentially you have to convert whatever other color space to pre-multiplied on the fly, to do the filtering. But I'm nitpicking. :-) Best regards, -Stephan ------------------------------------------------------------------------------ _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
|
|
Re: Blending and Drawing produce different image..Stephan Aßmus wrote:
> I would respectfully disagree, since essentially you have to convert > whatever other color space to pre-multiplied on the fly, to do the > filtering. But I'm nitpicking. :-) OK, I guess you could look at it that way :-) - Jim ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Vector-agg-general mailing list Vector-agg-general@... https://lists.sourceforge.net/lists/listinfo/vector-agg-general |
| Free embeddable forum powered by Nabble | Forum Help |