Nabble - Anti-Grain Geometry

Re: Custom pixel format in AGG

2009-11-26T05:24:20Z

John Horigan wrote:
> p[Order::A] = (foo) >> 5;

That's a reasonable approximation, and is very fast, of course. However,
the division is by 32 rather than 255/7 (~36.4) and the result is
truncated rather than rounded.

In 32-bit arithmetic, the following calculation gives the correctly
rounded result throughout the input range 0-255:

p[Order::A] = ((foo * 0x0707) + 0x8000) >> 16;

The following approximation is very close (off by one for 164, 201, 237)
and only requires 16-bit arithmetic:

p[Order::A] = ((foo * 0x07) + 0x80) >> 8;

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Custom pixel format in AGG

2009-11-25T09:27:16Z

You can use rgba8, but you will need to make your own blender and pixel format class because they directly access the alpha value and assume that it is 8-bit (or 16-bit).

But it shouldn't be too hard. Just take an existing blender and pixel format class and replace all occurrences of

p[Order::A] = foo; // or order_type::A

with

p[Order::A] = (foo) >> 5;

and all remaining p[Order::A] with (((p[Order::A} & 7) * 0111) >> 1) (NB, that is octal 0111, which is 73 in decimal).

-- john

On Nov 25, 2009, at 8:03 AM, sb wrote:

> Hello,
>
> I'd like to know how I might go about adding a pixel format where it's argb, but
> alpha is only given the 3 lower bits of the MSB. Meaning the the buffers are
> packed like this per pixel:
>
> bits 31-27 are not interpreted
> 26-24 are alpha
> 23-16 red, etc.
>
> What would be nice is to use the existing rgba8 color and blenders so I get a
> little more precision out, and then use something similar to the
> pixfmt_alpha_blend_rgba template to do some additional work in there to pack /
> unpack the alpha. I realize that reading out of the buffer will lose precision,
> but that's what I'd expect.
>
> Any advice on the approach is appreciated.
>
> Thanks,
>
> sb
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Custom pixel format in AGG

2009-11-25T09:07:36Z

sb wrote:

> I'd like to know how I might go about adding a pixel format where it's argb, but
> alpha is only given the 3 lower bits of the MSB. Meaning the the buffers are
> packed like this per pixel:
>
> bits 31-27 are not interpreted
> 26-24 are alpha
> 23-16 red, etc.
>
> What would be nice is to use the existing rgba8 color and blenders so I get a
> little more precision out, and then use something similar to the
> pixfmt_alpha_blend_rgba template to do some additional work in there to pack /
> unpack the alpha. I realize that reading out of the buffer will lose precision,
> but that's what I'd expect.

I think there are basically two approaches:

1) Write a blender_rgba replacement that implements blend_pix by
directly using your 3-bit alpha values. You'd have to write a
pixfmt_alpha_blend_rgba replacement as well, because it accesses the
alpha values too.

2) When "importing" images into AGG, expand your 3-bit alpha values to 8
bits, perhaps by using pixfmt_alpha_blend_rgba::for_each_pixel and a
suitable functor. When exporting, do the opposite.

I suggest the second approach, as it is much easier and will cause less
precision to be lost when blending.

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Custom pixel format in AGG

2009-11-25T08:03:15Z

Hello,

I'd like to know how I might go about adding a pixel format where it's argb, but
alpha is only given the 3 lower bits of the MSB. Meaning the the buffers are
packed like this per pixel:

bits 31-27 are not interpreted
26-24 are alpha
23-16 red, etc.

What would be nice is to use the existing rgba8 color and blenders so I get a
little more precision out, and then use something similar to the
pixfmt_alpha_blend_rgba template to do some additional work in there to pack /
unpack the alpha. I realize that reading out of the buffer will lose precision,
but that's what I'd expect.

Any advice on the approach is appreciated.

Thanks,

sb

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

bug is trans_affine::multiply [WAS: few questions from a beginner]

2009-11-18T14:57:58Z

2009/11/18 Francesco Abbate <francesco.bbt@...>:

> I've actually found myself the answer to my questions :-)
> For the affine transformation I've written myself the function:
>
> void
> trans_affine_compose (agg::trans_affine& a, const agg::trans_affine& b)
> {
> a.premultiply(b);
>
> double a_tx = b.sx * a.tx + b.shx * a.ty + b.tx;
> double a_ty = b.shy * a.tx + b.sy * a.ty + b.ty;
> a.tx = a_tx;
> a.ty = a_ty;
> }

Hi all,

at the beginning I was thinking that the multiply and premultiply
operations were just multiplying the matrices. It seems that this is
not the case and also the translations are taken into account.

For the other side it seems that there is a bug in
trans_affine::multiply and the tx and ty terms are not calculated
correctly. So, I've used a following workaround:

void
trans_affine_compose (agg::trans_affine& a, const agg::trans_affine& b)
{
double a_tx = a.tx, a_ty = a.ty;

a.premultiply(b);

a.tx = b.sx * a_tx + b.shx * a_ty + b.tx;
a.ty = b.shy * a_tx + b.sy * a_ty + b.ty;
}

Actually, the AGG implementation is omitting the term (b matrix) * (a trans).

May be I'm wrong but it would be nice if the owner could check this problem.

Best regards,
Francesco

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: few questions from a beginner

2009-11-18T13:16:18Z

2009/11/18 Petr Kobalíček <kobalicek.petr@...>:
> Hi Francesco,
>
> if you do not want do modify width by affine transformation then you
> can transform path before stroking, but I don't know if this is what
> you want (this means that line width will not be x/y scaled).

Hi Petr,

thank you very much, this is exactly what I need!

I'm beginning now to understand the pipeline architecture of AGG.
Unfortunately the typing system is very difficult to understand by
looking at code because of the extensive use of templates and the
absence of explicit 'interfaces' (à la Java).

Otherwise I'm impressed by the quality of the code and of the design
of the library. It is a pity that the documentation is incomplete but
I'm going to understand how it works, it takes just more time.

Thanks again but I think I will came soon with other questions.

Best regards,
Francesco

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: few questions from a beginner

2009-11-18T11:24:10Z

Hi Francesco,

if you do not want do modify width by affine transformation then you
can transform path before stroking, but I don't know if this is what
you want (this means that line width will not be x/y scaled).

Hope that helps

--
Best regards
- Petr Kobalicek <http://kobalicek.com>

On Wed, Nov 18, 2009 at 6:56 PM, Francesco Abbate
<francesco.bbt@...> wrote:

> hmmm,
>
> I've actually found myself the answer to my questions :-)
> For the affine transformation I've written myself the function:
>
> void
> trans_affine_compose (agg::trans_affine& a, const agg::trans_affine& b)
> {
> a.premultiply(b);
>
> double a_tx = b.sx * a.tx + b.shx * a.ty + b.tx;
> double a_ty = b.shy * a.tx + b.sy * a.ty + b.ty;
> a.tx = a_tx;
> a.ty = a_ty;
> }
>
> Talking about the line width, I've seen there is width method in the
> conv_stroke class so that's not a complicate affair. The only delicate
> thing is that the line width pass through the affine transformation
> and therefore can be highly modified if the affine transformation has
> big scale coeffs.
>
> Thank you anyway and best regards,
> Francesco
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: few questions from a beginner

2009-11-18T10:56:18Z

hmmm,

I've actually found myself the answer to my questions :-)
For the affine transformation I've written myself the function:

void
trans_affine_compose (agg::trans_affine& a, const agg::trans_affine& b)
{
a.premultiply(b);

double a_tx = b.sx * a.tx + b.shx * a.ty + b.tx;
double a_ty = b.shy * a.tx + b.sy * a.ty + b.ty;
a.tx = a_tx;
a.ty = a_ty;
}

Talking about the line width, I've seen there is width method in the
conv_stroke class so that's not a complicate affair. The only delicate
thing is that the line width pass through the affine transformation
and therefore can be highly modified if the affine transformation has
big scale coeffs.

Thank you anyway and best regards,
Francesco

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

few questions from a beginner

2009-11-18T09:42:21Z

Hi all,

I'm a beginner with AGG and I have some difficulties to understand
some details about rendering of polygonal lines. I'm using the
following sequence to plot a line:

agg::pixfmt_bgr24 pixf(rbuf_window());
agg::renderer_base<agg::pixfmt_bgr24> renb(pixf);
agg::renderer_scanline_aa_solid<agg::renderer_base<agg::pixfmt_bgr24>
> rs(renb);

agg::rasterizer_scanline_aa<> ras;
agg::scanline_u8 sl;

agg::path_storage p;
agg::conv_stroke<agg::path_storage> pl(p);
agg::conv_transform<agg::conv_stroke<agg::path_storage> > tr(pl, m);

where m is a custom affine transformation but I get a *very* thick
line. unfortunately I was not able to find the informations I need in
the AGG documentation. Could I have some hints about how should I
manage the line thickness ?

I've also another question about the affine transformations. Is there
any method to compose two *transformations*. The general affine
transformation can be written as:

y = M x + y0

where M is a square matrix. We can think at it like a function x -> y.
Then the composition of two transformations f and g should me the
function that associate g(f(x)) to x. So, in matrix term:

z = N M x + N y0 + z0

where N and z0 are the matrix and offset of the second transformation.

I will appreciate a lot any help but thank you very much in any case.

Best regards,
Francesco

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: agg render buffer and opengl

2009-11-17T04:05:50Z

Its easy enough - render in memory and give it to GL.
I dont think you have direct access to the hadrware buffer anyway.

Rough example:

std::vector<GLUint> textures_;
...
textures_.resize(tex_count);
glGenTextures(tex_count, &textures_[0]);

for (size_t n = 0; n < tex_count; ++n) {

glBindTexture(GL_TEXTURE_2D, textures_[n]);

std::vector<unsigned char> image(width * height * 3);
RenderMyImage(image, width, height);

        glTexImage2D(
            GL_TEXTURE_2D,                // GLenum target,
            0,                            // GLint level,
            3,                            // GLint internalformat,
            width,        // GLsizei width,
            height,        // GLsizei height,
            0,                            // GLint border,
            GL_RGB,                        // GLenum format,
            GL_UNSIGNED_BYTE,            // GLenum type,
            image            // const GLvoid *pixels
        );

}

Stephan Assmus wrote:

On 2009-11-03 at 19:16:25 [+0100], Jim Crafton jim.crafton@... 
wrote:

I'm contemplating making an image editor of sorts, something that's based 
on another library of mine that roughly duplicates Apple's CoreImage on 
Windows. It uses OpenGL to draw images and GLSL for filters that can 
added to an image for processing the pixels. What I'd like to do is also 
use AGG to draw on the opengl image, which is just a texture map. Any 
advice on how best to approach this? Is it just a matter of creating a 
texture and dumping the contents of AGG's render_buffer onto the texture 
bits?


Depending on your setup, it may be faster to render in main memory and copy 
the buffer into the textture. But it could also be possible to attach the 
agg::render_buffer directly to the texture buffer. I assume you need to 
lock the OpenGL context during rendering. And this will involve 
read-operations, which could very well be slow if the texture lives in 
graphics memory. Another option may be to declare the texture such that the 
graphics chip pulls it itself from main memory. That could be faster than 
manually copying the buffer into the texture allocated in graphics memory. 
For how to do this exactly, you will need to look into OpenGL 
documentation, I am just assuming this is possible and advise from my own 
experience in similar situations, but not with OpenGL in particular. (My 
experience is with using old-school video overlays, but those live in video 
memory too, so the situation is similar with regard to what is fast and 
what is slow if you attach AGG to it.)

Best regards,
-Stephan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-17T02:14:07Z

On 2009-11-17 at 08:01:49 [+0100], John Horigan <john@...> wrote:
> It was very painful, but I got aa_test to build under Ubuntu and
> reproduced jay3d's issue.
>
> I applied fixes for the two bugs pointed out by Jim Barry. Fixing these
> two bugs restored anti-aliasing to aa_test.

Thanks a bunch!

Best regards,
-Stephan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-16T23:01:49Z

It was very painful, but I got aa_test to build under Ubuntu and reproduced jay3d's issue.

I applied fixes for the two bugs pointed out by Jim Barry. Fixing these two bugs restored anti-aliasing to aa_test.

Here is a patch:

-- john

On Nov 16, 2009, at 3:25 PM, John Horigan wrote:

> I can't get aa_test to build on my system (Mac OS X 10.6.2). I will try it in a Ubuntu VM. Meanwhile, renderer_scanline_aa_solid<> generates properly anti-aliased output in my own application. And the image posted by Jim Barry is properly anti-aliased too (although the end-caps are the wrong color).
>
> -- john
>
>
> On Nov 16, 2009, at 11:05 AM, Stephan Assmus wrote:
>
>>
>> On 2009-11-11 at 16:58:05 [+0100], Jim Barry <jim@...> wrote:
>>> John Horigan wrote:
>>>> Ah, I missed that one. I can't see any more that I've missed. Can you
>>> give a look?
>>>
>>> I haven't spotted any others yet, but I found another problem. The bottom
>>> of the "ice lolly sticks" are not rendered correctly (see attached
>>> image). It took me a little while to figure out the reason, but in rgba8
>>> we have:
>>>
>>> AGG_INLINE self_type gradient(const self_type& c, double k) const {
>>> self_type ret;
>>> calc_type ik = uround(k * base_scale);
>>> ret.r = (value_type)int_lerp(r, c.r, ik);
>>> ret.g = (value_type)int_lerp(g, c.g, ik);
>>> ret.b = (value_type)int_lerp(b, c.b, ik);
>>> ret.a = (value_type)int_lerp(a, c.a, ik);
>>> return ret;
>>> }
>>>
>>> In 8-bit formats, you're lerping in the range 0-256 instead of 0-255. You
>>> need to use "base_mask" instead of "base_scale". The same applies to
>>> rgba16, of course.
>>
>> <nugde>
>>
>> John, have you found any time to look into this already?
>>
>> Best regards,
>> -Stephan
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Vector-agg-general mailing list
>> Vector-agg-general@...
>> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

agg24_alvyraysmith_bugfix1.patch (2K) Download Attachment

Re: aa_test is not antiliased (jagged), a bug?

2009-11-16T15:25:38Z

I can't get aa_test to build on my system (Mac OS X 10.6.2). I will try it in a Ubuntu VM. Meanwhile, renderer_scanline_aa_solid<> generates properly anti-aliased output in my own application. And the image posted by Jim Barry is properly anti-aliased too (although the end-caps are the wrong color).

-- john

On Nov 16, 2009, at 11:05 AM, Stephan Assmus wrote:

>
> On 2009-11-11 at 16:58:05 [+0100], Jim Barry <jim@...> wrote:
>> John Horigan wrote:
>>> Ah, I missed that one. I can't see any more that I've missed. Can you
>> give a look?
>>
>> I haven't spotted any others yet, but I found another problem. The bottom
>> of the "ice lolly sticks" are not rendered correctly (see attached
>> image). It took me a little while to figure out the reason, but in rgba8
>> we have:
>>
>> AGG_INLINE self_type gradient(const self_type& c, double k) const {
>> self_type ret;
>> calc_type ik = uround(k * base_scale);
>> ret.r = (value_type)int_lerp(r, c.r, ik);
>> ret.g = (value_type)int_lerp(g, c.g, ik);
>> ret.b = (value_type)int_lerp(b, c.b, ik);
>> ret.a = (value_type)int_lerp(a, c.a, ik);
>> return ret;
>> }
>>
>> In 8-bit formats, you're lerping in the range 0-256 instead of 0-255. You
>> need to use "base_mask" instead of "base_scale". The same applies to
>> rgba16, of course.
>
> <nugde>
>
> John, have you found any time to look into this already?
>
> Best regards,
> -Stephan
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: agg render buffer and opengl

2009-11-16T11:49:20Z

Thanks for the info!

Cheers

Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-16T11:05:04Z

On 2009-11-11 at 16:58:05 [+0100], Jim Barry <jim@...> wrote:

> John Horigan wrote:
> > Ah, I missed that one. I can't see any more that I've missed. Can you
> give a look?
>
> I haven't spotted any others yet, but I found another problem. The bottom
> of the "ice lolly sticks" are not rendered correctly (see attached
> image). It took me a little while to figure out the reason, but in rgba8
> we have:
>
> AGG_INLINE self_type gradient(const self_type& c, double k) const {
> self_type ret;
> calc_type ik = uround(k * base_scale);
> ret.r = (value_type)int_lerp(r, c.r, ik);
> ret.g = (value_type)int_lerp(g, c.g, ik);
> ret.b = (value_type)int_lerp(b, c.b, ik);
> ret.a = (value_type)int_lerp(a, c.a, ik);
> return ret;
> }
>
> In 8-bit formats, you're lerping in the range 0-256 instead of 0-255. You
> need to use "base_mask" instead of "base_scale". The same applies to
> rgba16, of course.

<nugde>

John, have you found any time to look into this already?

Best regards,
-Stephan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: agg render buffer and opengl

2009-11-16T10:55:50Z

On 2009-11-03 at 19:16:25 [+0100], Jim Crafton <jim.crafton@...>
wrote:
> I'm contemplating making an image editor of sorts, something that's based
> on another library of mine that roughly duplicates Apple's CoreImage on
> Windows. It uses OpenGL to draw images and GLSL for filters that can
> added to an image for processing the pixels. What I'd like to do is also
> use AGG to draw on the opengl image, which is just a texture map. Any
> advice on how best to approach this? Is it just a matter of creating a
> texture and dumping the contents of AGG's render_buffer onto the texture
> bits?

Depending on your setup, it may be faster to render in main memory and copy
the buffer into the textture. But it could also be possible to attach the
agg::render_buffer directly to the texture buffer. I assume you need to
lock the OpenGL context during rendering. And this will involve
read-operations, which could very well be slow if the texture lives in
graphics memory. Another option may be to declare the texture such that the
graphics chip pulls it itself from main memory. That could be faster than
manually copying the buffer into the texture allocated in graphics memory.
For how to do this exactly, you will need to look into OpenGL
documentation, I am just assuming this is possible and advise from my own
experience in similar situations, but not with OpenGL in particular. (My
experience is with using old-school video overlays, but those live in video
memory too, so the situation is similar with regard to what is fast and
what is slow if you attach AGG to it.)

Best regards,
-Stephan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-11T07:58:05Z

John Horigan wrote:
> Ah, I missed that one. I can't see any more that I've missed. Can you
give a look?

I haven't spotted any others yet, but I found another problem. The
bottom of the "ice lolly sticks" are not rendered correctly (see
attached image). It took me a little while to figure out the reason, but
in rgba8 we have:

AGG_INLINE self_type gradient(const self_type& c, double k) const
{
self_type ret;
calc_type ik = uround(k * base_scale);
ret.r = (value_type)int_lerp(r, c.r, ik);
ret.g = (value_type)int_lerp(g, c.g, ik);
ret.b = (value_type)int_lerp(b, c.b, ik);
ret.a = (value_type)int_lerp(a, c.a, ik);
return ret;
}

In 8-bit formats, you're lerping in the range 0-256 instead of 0-255.
You need to use "base_mask" instead of "base_scale". The same applies to
rgba16, of course.

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

aa_test.png (29K) Download Attachment

Re: aa_test is not antiliased (jagged), a bug?

2009-11-10T12:30:57Z

Ah, I missed that one. I can't see any more that I've missed. Can you give a look?

I'll send out patch fixing this bug as soon as we get to the bottom of this aa_test failure. I can't even get it to build on my system (a mac).

-- john

On Nov 10, 2009, at 11:13 AM, Jim Barry wrote:

> John Horigan wrote:
>> In the blender class blend_pix() method you will find:
>> alpha = color_type::int_mult_cover(alpha, cover);
>>
>> This is part of the patch. The int_mult_cover(alpha, cover) has been moved from pixfmt_alpha_blender_* to the blender class blend_pix () method. This was done to improve efficiency and expose parallelism.
>
> OK, I see. So it's just that you forgot to add an int_mult_cover call to
> blender_rgb_gamma::blend_pix.
>
> Actually it did seem like a bit of an anomaly that the original version
> of pixfmt_alpha_blend_rgb[a] prelerped the alpha before calling
> blend_pix - other pixel formats don't do that.
>
> - Jim
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-10T11:13:07Z

John Horigan wrote:
> In the blender class blend_pix() method you will find:
> alpha = color_type::int_mult_cover(alpha, cover);
>
> This is part of the patch. The int_mult_cover(alpha, cover) has been moved from pixfmt_alpha_blender_* to the blender class blend_pix () method. This was done to improve efficiency and expose parallelism.

OK, I see. So it's just that you forgot to add an int_mult_cover call to
blender_rgb_gamma::blend_pix.

Actually it did seem like a bit of an anomaly that the original version
of pixfmt_alpha_blend_rgb[a] prelerped the alpha before calling
blend_pix - other pixel formats don't do that.

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-10T08:22:06Z

In the blender class blend_pix() method you will find:
alpha = color_type::int_mult_cover(alpha, cover);

This is part of the patch. The int_mult_cover(alpha, cover) has been moved from pixfmt_alpha_blender_* to the blender class blend_pix () method. This was done to improve efficiency and expose parallelism.

My own code uses renderer_scanline_aa_solid<> and it produces anti-aliased output. I will pull the latest copy of agg from svn and see if it is different than what I am compiling my code against.

-- john

On Nov 10, 2009, at 3:33 AM, Jim Barry wrote:

> John Horigan wrote:
>> I believe that the patch is correct:
>
> Compiling and running aa_test proves otherwise ;-)
>
>> int_mult_cover(255, 254) == 254 (rgb8)
>> int_mult_cover(65534, 255) == 65534 && int_mult_cover(65535, 254) ==
>> 65278 (rgb16)
>>
>> int_mult_cover(c.a, cover) equals base_mask if and only if c.a equals
>> base_mask and cover equals cover_mask. So the two if statement
>> conditions are equivalent.
>
> Yes, but the problem is that you pass c.a to blend_pix instead of (c.a *
> cover / cover_full). So you *could* write:
>
> if (c.a)
> {
> if(c.a == base_mask && cover == cover_mask)
> {
> p[order_type::R] = c.r;
> p[order_type::G] = c.g;
> p[order_type::B] = c.b;
> }
> else
> {
> calc_type alpha = color_type::int_mult_cover(c.a, cover);
> m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
> }
> }
>
> Is this more or less efficient than the version I proposed before? I
> don't know. I suppose it depends how many of the source pixels are fully
> opaque.
>
> - Jim
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-10T03:33:49Z

John Horigan wrote:
> I believe that the patch is correct:

Compiling and running aa_test proves otherwise ;-)

> int_mult_cover(255, 254) == 254 (rgb8)
> int_mult_cover(65534, 255) == 65534 && int_mult_cover(65535, 254) ==
> 65278 (rgb16)
>
> int_mult_cover(c.a, cover) equals base_mask if and only if c.a equals
> base_mask and cover equals cover_mask. So the two if statement
> conditions are equivalent.

Yes, but the problem is that you pass c.a to blend_pix instead of (c.a *
cover / cover_full). So you *could* write:

if (c.a)
{
if(c.a == base_mask && cover == cover_mask)
{
p[order_type::R] = c.r;
p[order_type::G] = c.g;
p[order_type::B] = c.b;
}
else
{
calc_type alpha = color_type::int_mult_cover(c.a, cover);
m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
}
}

Is this more or less efficient than the version I proposed before? I
don't know. I suppose it depends how many of the source pixels are fully
opaque.

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-09T22:38:35Z

I believe that the patch is correct:
int_mult_cover(255, 254) == 254 (rgb8)
int_mult_cover(65534, 255) == 65534 && int_mult_cover(65535, 254) ==
65278 (rgb16)

int_mult_cover(c.a, cover) equals base_mask if and only if c.a equals
base_mask and cover equals cover_mask. So the two if statement
conditions are equivalent.

-- john

On Nov 9, 2009, at 10:48 AM, Jim Barry wrote:

> jay3d wrote:
>> The aa-test demo in the latest svn is not antialiased!
>>
>> is it a known bug?
>
> Seems to be a problem with the recent "accurate blending" patch.
>
> In pixfmt_alpha_blend_rgb::copy_or_blend_pix, we used to have:
>
> if (c.a)
> {
> calc_type alpha = (calc_type(c.a) * (cover + 1)) >> 8;
> if(alpha == base_mask)
> {
> p[order_type::R] = c.r;
> p[order_type::G] = c.g;
> p[order_type::B] = c.b;
> }
> else
> {
> m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
> }
> }
>
> The patch changed this to:
>
> if (c.a)
> {
> if(c.a == base_mask && cover == cover_mask)
> {
> p[order_type::R] = c.r;
> p[order_type::G] = c.g;
> p[order_type::B] = c.b;
> }
> else
> {
> m_blender.blend_pix(p, c.r, c.g, c.b, c.a, cover);
> }
> }
>
> Which is not correct. I think it should be something like this:
>
> if (c.a)
> {
> calc_type alpha = color_type::int_mult_cover(c.a, cover);
> if(alpha == base_mask)
> {
> p[order_type::R] = c.r;
> p[order_type::G] = c.g;
> p[order_type::B] = c.b;
> }
> else
> {
> m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
> }
> }
>
> The same applies to blend_hline, blend_vline, blend_solid_hspan, and
> blend_solid_vspan.
>
> - Jim
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: aa_test is not antiliased (jagged), a bug?

2009-11-09T10:48:46Z

jay3d wrote:
> The aa-test demo in the latest svn is not antialiased!
>
> is it a known bug?

Seems to be a problem with the recent "accurate blending" patch.

In pixfmt_alpha_blend_rgb::copy_or_blend_pix, we used to have:

if (c.a)
{
calc_type alpha = (calc_type(c.a) * (cover + 1)) >> 8;
if(alpha == base_mask)
{
p[order_type::R] = c.r;
p[order_type::G] = c.g;
p[order_type::B] = c.b;
}
else
{
m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
}
}

The patch changed this to:

if (c.a)
{
if(c.a == base_mask && cover == cover_mask)
{
p[order_type::R] = c.r;
p[order_type::G] = c.g;
p[order_type::B] = c.b;
}
else
{
m_blender.blend_pix(p, c.r, c.g, c.b, c.a, cover);
}
}

Which is not correct. I think it should be something like this:

if (c.a)
{
calc_type alpha = color_type::int_mult_cover(c.a, cover);
if(alpha == base_mask)
{
p[order_type::R] = c.r;
p[order_type::G] = c.g;
p[order_type::B] = c.b;
}
else
{
m_blender.blend_pix(p, c.r, c.g, c.b, alpha, cover);
}
}

The same applies to blend_hline, blend_vline, blend_solid_hspan, and
blend_solid_vspan.

- Jim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

aa_test is not antiliased (jagged), a bug?

2009-11-07T11:39:15Z

The aa-test demo in the latest svn is not antialiased!

is it a known bug?

using VS2008 SP1

Thanks!

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: agg render buffer and opengl

2009-11-03T20:14:29Z

Possible. U can use the memory provided to agg::rendering_buffer. Make
pixel format for the render buffer and texture are same.

unsigned long *buffer = new unsigned long[width*height*4];
memset(buffer, 0, width * height* 4);

agg::rendering_buffer r_buf_(buffer, width, height, width * 4);

//Do ur rendreing

//Copy buffer to texture

Jim Crafton wrote:

> I'm contemplating making an image editor of sorts, something that's
> based on another library of mine that roughly duplicates Apple's
> CoreImage on Windows. It uses OpenGL to draw images and GLSL for
> filters that can added to an image for processing the pixels. What I'd
> like to do is also use AGG to draw on the opengl image, which is just
> a texture map. Any advice on how best to approach this? Is it just a
> matter of creating a texture and dumping the contents of AGG's
> render_buffer onto the texture bits?
>
> Thanks!
>
> Jim
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>
>

#define ENABLE_LTDL 0

2009-11-03T11:11:29Z

I am building a minimal dot build, which will take a dot file in and output
an SVG fil only (ultimately I will make it a single DLL, but for now several
DLLs is fine).

I have built the solution with ENABLE_LTDL = 0 (as well as all the PNG JPEG
etc = 0) and am able to run dot from the command line, but I get the
following error:
Unable to find even the default "-Tdot" renderer. Has the config
file been generated by running "dot -c" with installer's priviledges?

>From digging around look like I need to use some predefined structs for the
SVG "plugin", but am not sure where to declare (and how to declare) and how
to initialize, any help appreciated.

Gordon.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

agg render buffer and opengl

2009-11-03T10:16:25Z

I'm contemplating making an image editor of sorts, something that's
based on another library of mine that roughly duplicates Apple's
CoreImage on Windows. It uses OpenGL to draw images and GLSL for
filters that can added to an image for processing the pixels. What I'd
like to do is also use AGG to draw on the opengl image, which is just
a texture map. Any advice on how best to approach this? Is it just a
matter of creating a texture and dumping the contents of AGG's
render_buffer onto the texture bits?

Thanks!

Jim

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Feedback: Ray-Alvy-Smith patch, SVN

2009-10-19T12:19:37Z

Hi All,

We waited for more then enough.
Have not seen objection.
Will apply the patch tomorrow in say 24 hours.

Regards,

Klaas

John Horigan wrote:
>
> OK. I will incorporate that. New patch attached.
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: SVN (SourceForge ID)

2009-10-07T09:20:09Z

thevinn has been added to the project

editor rights has been added

--- On Wed, 9/16/09, Vinnie <thevinn@...> wrote:

> From: Vinnie <thevinn@...>
> Subject: Re: [AGG] SVN (SourceForge ID)
> To: vector-agg-general@...
> Date: Wednesday, September 16, 2009, 8:25 AM
> > Date: Wed, 26 Aug 2009 23:35:01
> +0200
> > From: "klaas.holwerda" <ngi@...>
> > Please post your Source Forge ID to grant you
> developer
> > access
> >
> > Is there a problem doing that?
>
> Apparently yes because it was over 3 weeks since I sent the
> message, and I have not received any Vector-agg digests. I
> just now read your reply. Sorry for the inconvenience!
>
> My SourceForge ID is thevinn
>
> Thank you for your consideration.
>
> Sincerely,
>
> Vinnie
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer
> Conference in SF, CA
> is the only developer event you need to attend this year.
> Jumpstart your
> developing skills, take BlackBerry mobile applications to
> market and stay
> ahead of the curve. Join us from November 9-12, 2009.
> Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Feedback: Ray-Alvy-Smith patch, SVN

2009-10-03T09:51:11Z

On Oct 3, 2009, at 5:10 AM, Vinnie wrote:

> - I was able to get the patch from the last post, I saw it both in
> my private message and also the message posted to the list. Thanks
>
> - Patch worked great!
>
> - When I looked at my customizations, there was really only one
> thing that i added, an enumeration value to each of the orders:
>
> struct order_rgb { enum rgb_e { R=0, G=1, B=2, rgb_tag,
> hasAlpha=false }; }; //----order_rgb
> struct order_bgr { enum bgr_e { B=0, G=1, R=2, rgb_tag,
> hasAlpha=false }; }; //----order_bgr
> struct order_rgba { enum rgba_e { R=0, G=1, B=2, A=3, rgba_tag,
> hasAlpha=true }; }; //----order_rgba
> struct order_argb { enum argb_e { A=0, R=1, G=2, B=3, rgba_tag,
> hasAlpha=true }; }; //----order_argb
> struct order_abgr { enum abgr_e { A=0, B=1, G=2, R=3, rgba_tag,
> hasAlpha=true }; }; //----order_abgr
> struct order_bgra { enum bgra_e { B=0, G=1, R=2, A=3, rgba_tag,
> hasAlpha=true }; }; //----order_bgra
>
> My change was to include 'hasAlpha'. This is useful for template
> metaprogramming.
>

OK. I will incorporate that. New patch attached.

> - I have a common header file at the beginning of every .cpp file in
> the agg project, #include "pch.h" for building a precompiled header
> under MSVC
>
>

Sounds great. You should create a patch for that. Wrap the #include in
something like #ifdef AGG_USE_MSVC_PCH so that other Windows users are
not compelled to use pre-compiled headers.

> Also:
>
> - The directory structure of the project could be improved. The
> extra 'agg-2.4' is pretty annoying, as is the lack of a single
> include directory. It was one of the first things I changed in my
> private copy and I had to revert it back in order to apply the
> patch. I was thinking:
>
> {agg dir}include/agg/*
> {agg dir}include/agg/ctrl/*
> {agg dir}include/agg/platform/*
> ...
> {agg dir}include/agg/freetype/{freetype includes}
> {agg dir}include/agg/win_truetype/{win truetype includes}
> {agg dir}src/*
> ...
>
> This way a build environment can use -I{agg dir}include, with client
> code having lines like:
> #include <agg/agg_arrowhead.h>
> or (more work)
> #include <agg/arrowhead.h>
> for example.
>
> Of course this is a non trivial change that might require client
> code changes (mostly search and replace) but I wanted to mention it.
>

This is a great idea. We could do this trivially use symbolic links
but SVN doesn't even try to support symbolic links under Windows.
Maybe you could create your preferred include tree using symlinks (if
you are running Vista or Win7).

We should have a list of major improvements to AGG. Then at some date
we could have a hacking sprint and produce AGG3. Reorganizing the
header files should be on the list.

> - Still no SVN access unless I am doing something wrong (?)
>
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

agg24_alvyraysmithOct0309.patch.gz (7K) Download Attachment

Feedback: Ray-Alvy-Smith patch, SVN

2009-10-03T05:10:11Z

- I was able to get the patch from the last post, I saw it both in my private message and also the message posted to the list. Thanks

- Patch worked great!

- When I looked at my customizations, there was really only one thing that i added, an enumeration value to each of the orders:

struct order_rgb { enum rgb_e { R=0, G=1, B=2, rgb_tag, hasAlpha=false }; }; //----order_rgb
struct order_bgr { enum bgr_e { B=0, G=1, R=2, rgb_tag, hasAlpha=false }; }; //----order_bgr
struct order_rgba { enum rgba_e { R=0, G=1, B=2, A=3, rgba_tag, hasAlpha=true }; }; //----order_rgba
struct order_argb { enum argb_e { A=0, R=1, G=2, B=3, rgba_tag, hasAlpha=true }; }; //----order_argb
struct order_abgr { enum abgr_e { A=0, B=1, G=2, R=3, rgba_tag, hasAlpha=true }; }; //----order_abgr
struct order_bgra { enum bgra_e { B=0, G=1, R=2, A=3, rgba_tag, hasAlpha=true }; }; //----order_bgra

My change was to include 'hasAlpha'. This is useful for template metaprogramming.

- I have a common header file at the beginning of every .cpp file in the agg project, #include "pch.h" for building a precompiled header under MSVC

Also:

- The directory structure of the project could be improved. The extra 'agg-2.4' is pretty annoying, as is the lack of a single include directory. It was one of the first things I changed in my private copy and I had to revert it back in order to apply the patch. I was thinking:

{agg dir}include/agg/*
{agg dir}include/agg/ctrl/*
{agg dir}include/agg/platform/*
...
{agg dir}include/agg/freetype/{freetype includes}
{agg dir}include/agg/win_truetype/{win truetype includes}
{agg dir}src/*
...

This way a build environment can use -I{agg dir}include, with client code having lines like:
#include <agg/agg_arrowhead.h>
or (more work)
#include <agg/arrowhead.h>
for example.

Of course this is a non trivial change that might require client code changes (mostly search and replace) but I wanted to mention it.

- Still no SVN access unless I am doing something wrong (?)

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-10-02T23:19:39Z

A gzipped patch file is attached. If you don't see an attachment then
contact me and I will arrange some other method of getting the patch
to you.

Updated patch for accurate blenders:
1) Old blenders are completely removed
2) both gray16(const rgba16&) constructors are fixed

-- john

On Oct 2, 2009, at 3:19 PM, John Horigan wrote:

> Yes, that is a bug in my new gray16() constructor. I will send out a
> new patch with that fixed and the old code removed.
>
> -- john
>
> On Oct 2, 2009, at 10:13 AM, klaas.holwerda wrote:
>
>> Stephan Assmus wrote:
>>> Hi John,
>>>
>>> On 2009-09-28 at 00:12:42 [+0200], John Horigan <john@...>
>>> wrote:
>>>
>>>> Sorry for the delay in this patch. I thought that the new blenders
>>>> were
>>>> failing in the rgba16 formats. But it turned out that the error
>>>> was in my
>>>> test framework.
>>>>
>>>
>>> I've read through the patch and it looks very good! Thanks a lot
>>> for this
>>> work. Only one place I am not sure about:
>>>
>>> +
>>> //--------------------------------------------------------------------
>>> + gray16(const rgba16& c, unsigned a_) :
>>> + v((value_type)((c.r*77 + c.g*150 + c.b*29) >> 16)),
>>> + a((value_type)a_) {}
>>>
>>> I think the shift is wrong, since 77 + 150 + 29 = 256.
>>>
>>> Has anybody else here already commited this patch?
>> I think not, can you do it?
>> Although i thinks legacy and incorrect blending code in AGG should be
>> removed. I agree with John on that and/or the husband.
>> It is bad to keep all old code around.
>> What do you think?
>>> I do not follow the AGG
>>> commits, is there a commit notification list I can sign up to?
>>>
>> Not yet, and only the admin can do it.
>> I suggest our admin gives other devlopers admin rights too.
>> Or at least make things happen more quickly. e.g. Vinnie is not on
>> the
>> members list jet.
>> And this commit list should be in place.
>>
>> Leonardo were are you??
>>
>> regards,
>>
>> Klaas
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF,
>> CA
>> is the only developer event you need to attend this year. Jumpstart
>> your
>> developing skills, take BlackBerry mobile applications to market and
>> stay
>> ahead of the curve. Join us from November 9-12, 2009. Register
>> now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Vector-agg-general mailing list
>> Vector-agg-general@...
>> https://lists.sourceforge.net/lists/listinfo/vector-agg-general
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

agg24_alvyraysmithOct0209.patch.gz (7K) Download Attachment

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-10-02T15:27:27Z

The patch does not fix the 15/16 bit formats. The patch is based on
the theory in Alvy Ray Smith's paper:
http://www.ozonehouse.com/john/4_Comp.pdf

It shouldn't be too hard to adapt this work to 5 or 6-bit color
components.

-- john

On Oct 2, 2009, at 4:21 AM, Udo Giacomozzi wrote:

> Hi John,
>
> does your patch also improve blending accuracy when using 15 or 16 bit
> ("hicolor") formats? We experience noticeable artifacts in those modes
> in Gnash...
>
> Udo
>
>
> Monday, August 17, 2009, 8:36:17 AM, you wrote:
>
>
> For my digital art program, Context Free, I have been using a
> modified form of the RGBA, RGB, and gray pixel formats. I do this
> because stock AGG is slightly inaccurate in computing and blending
> colors. My changes to AGG are based on Alvy Ray Smith's paper on
> fast, accurate color blending (ftp://ftp.alvyray.com/Acrobat/4_Comp.pdf
> ).
>
> The changes that I have made are:
> * Utility methods have been added to classes rgb8, rgb16, gray8, and
> gray16 for doing fast, accurate fixed point multiplies and linear
> interpolations.
> * The add, gradient, and premultiply methods of classes rgb8, rgb16,
> gray8, and gray16 use the new utility methods.
> * multiplier_rgba<>::premultiply() method in agg_pixfmt_rgba.h uses
> the new utility methods.
> * All of the blender classes in agg_pixfmt_gray/rbg/rgba.h use the
> new utility methods.
> * The interface between these blender classes and the pixfmt classes
> has been changed slightly. Currently the pixfmt class multiplies the
> color alpha with pixel coverage factor before calling the blender
> (even though both alpha and cover are passed to the blender). With
> this patch, this calculation is moved to the blender class blend_pix
> () methods.
> * I added a utility method to class rect_base in agg_basics.h:
> overlaps()
>
> I have been using most of these changes for over a year in Context
> Free and I am confident in their correctness. I don't use the non-
> premultiplied color blenders but I was able to tweak Context Free to
> use them and they appeared to function correctly.
>
> The composition operation classes comp_op_rgba_x in
> agg_pixfmt_rgba.h and the pixfmt_custom_blend_rgba class that uses
> them have not been updated to use the new utility methods. The
> composition operators could stand to be implemented more accurately,
> but I don't have any test bench for validating changes.
>
> The patch can be found at http://www.ozonehouse.com/john/agg24_alvyraysmith.patch
>
> -- john
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-10-02T15:19:26Z

Yes, that is a bug in my new gray16() constructor. I will send out a
new patch with that fixed and the old code removed.

-- john

On Oct 2, 2009, at 10:13 AM, klaas.holwerda wrote:

> Stephan Assmus wrote:
>> Hi John,
>>
>> On 2009-09-28 at 00:12:42 [+0200], John Horigan <john@...>
>> wrote:
>>
>>> Sorry for the delay in this patch. I thought that the new blenders
>>> were
>>> failing in the rgba16 formats. But it turned out that the error
>>> was in my
>>> test framework.
>>>
>>
>> I've read through the patch and it looks very good! Thanks a lot
>> for this
>> work. Only one place I am not sure about:
>>
>> +
>> //--------------------------------------------------------------------
>> + gray16(const rgba16& c, unsigned a_) :
>> + v((value_type)((c.r*77 + c.g*150 + c.b*29) >> 16)),
>> + a((value_type)a_) {}
>>
>> I think the shift is wrong, since 77 + 150 + 29 = 256.
>>
>> Has anybody else here already commited this patch?
> I think not, can you do it?
> Although i thinks legacy and incorrect blending code in AGG should be
> removed. I agree with John on that and/or the husband.
> It is bad to keep all old code around.
> What do you think?
>> I do not follow the AGG
>> commits, is there a commit notification list I can sign up to?
>>
> Not yet, and only the admin can do it.
> I suggest our admin gives other devlopers admin rights too.
> Or at least make things happen more quickly. e.g. Vinnie is not on the
> members list jet.
> And this commit list should be in place.
>
> Leonardo were are you??
>
> regards,
>
> Klaas
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Vector-agg-general mailing list
> Vector-agg-general@...
> https://lists.sourceforge.net/lists/listinfo/vector-agg-general

Re: Patch to improve blending accuracy of RGBA/RGB/Gray pixel formats

2009-10-02T10:13:00Z

Stephan Assmus wrote:

> Hi John,
>
> On 2009-09-28 at 00:12:42 [+0200], John Horigan <john@...> wrote:
>
>> Sorry for the delay in this patch. I thought that the new blenders were
>> failing in the rgba16 formats. But it turned out that the error was in my
>> test framework.
>>
>
> I've read through the patch and it looks very good! Thanks a lot for this
> work. Only one place I am not sure about:
>
> +
> //--------------------------------------------------------------------
> + gray16(const rgba16& c, unsigned a_) :
> + v((value_type)((c.r*77 + c.g*150 + c.b*29) >> 16)),
> + a((value_type)a_) {}
>
> I think the shift is wrong, since 77 + 150 + 29 = 256.
>
> Has anybody else here already commited this patch?

I think not, can you do it?
Although i thinks legacy and incorrect blending code in AGG should be
removed. I agree with John on that and/or the husband.
It is bad to keep all old code around.
What do you think?
> I do not follow the AGG
> commits, is there a commit notification list I can sign up to?
>
Not yet, and only the admin can do it.
I suggest our admin gives other devlopers admin rights too.
Or at least make things happen more quickly. e.g. Vinnie is not on the
members list jet.
And this commit list should be in place.

Leonardo were are you??

regards,

Klaas

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general