Re: [matplotlib-devel] [Fwd: [wxPython-users] Re: using wxImage in C++ python extension]

[John H. <jdh...@ac...>]

>>>>> "Ken" == Ken McIvor <mc...@ii...> writes:

    Ken> On 08/31/06 13:43, Christopher Barker wrote:
    >> Ken McIvor wrote:
    >> 
    >> a wxBitmap is the same format as the native rendering
    >> system. While most systems use 24b RGB (or 32b RGBA), people
    >> can still run displays at 16bpp or whatever, so it's still
    >> needed.

    Ken> I can understand why it's still necessary, although it's nice
    Ken> to sometimes pretend that everyone's running 24-bit color
    Ken> displays.  I hope I didn't sound too judgemental!

    >>> I don't think we're going to be able to get performance
    >>> similar to that of the accelerator using straight Python code
    >>  But whether it's Python or C++, you still need to do the
    >> Image->Bitmap conversion -- so if we can get rid of the data
    >> copying from Agg buffer to wxImage in Python, we don't need
    >> C++.

    Ken> I think we got some wires crossed at some point in the
    Ken> conversation, although it could be that I'm wearing the
    Ken> Stupid Hat today.  I was talking about the
    Ken> image-from-a-buffer business not helping us with WX 2.4/2.6
    Ken> due to the RGBA to RGB conversion.

    >> And it has. For wxPython 2.7 (and now in CVS) there are methods
    >> for dumping 32 bit RGBA data directly into a wxBitmap with no
    >> copying, if the data source is a Python Buffer object. I think
    >> I posted a note about this here yesterday.

    Ken> Yes, you did mention it.  I agree completely with this
    Ken> analysis of the situation.  When I replied I wasn't thinking
    Ken> in terms of wxPython 2.7.

    >> To really get it to work, the 24bit RGB Agg buffer needs to be
    >> a Python Buffer object -- is it now? I'm sorry I don't have the
    >> time to mess with this now -- maybe some day.

    Ken> I guess Guido lets John borrow his time machine, because
    Ken> RendererAgg appears to already have a buffer_rgba() method.

Guido has been very generous with us :-)

    >> You can alpha composite into a non-alpha background. You just
    >> lose the alpha there, so that the background couldn't be
    >> alpha-composited onto anything else -- but does it ever need to
    >> be?

    Ken> I thought that the buffer's accumulated alpha played a role
    Ken> in compositing new pixels onto it, but I apparently
    Ken> misunderstood. 

It does: here is agg's rgba pixel blending routing

        static AGG_INLINE void blend_pix(value_type* p, 
                                         unsigned cr, unsigned cg, unsigned cb,
                                         unsigned alpha, 
                                         unsigned cover=0)
        {
            calc_type r = p[Order::R];
            calc_type g = p[Order::G];
            calc_type b = p[Order::B];
            calc_type a = p[Order::A];
            p[Order::R] = (value_type)(((cr - r) * alpha + (r << base_shift)) >> base_shift);
            p[Order::G] = (value_type)(((cg - g) * alpha + (g << base_shift)) >> base_shift);
            p[Order::B] = (value_type)(((cb - b) * alpha + (b << base_shift)) >> base_shift);
            p[Order::A] = (value_type)((alpha + a) - ((alpha * a + base_mask) >> base_shift));
        }


    Ken> Images.  Anyway, if the buffer's alpha channel isn't used,
    Ken> then the whole situation does seem a bit odd.  Could the
    Ken> information be retained for PNGs or something?

It is useful to store the final pixel buffer (eg in a PNG) as RGBA
because some people like to have some parts of their figure
transparent to composite the figure with other images.

JDH