Fast 2D Raster Rendering with GUI

[dave]

Hi All. I've been formulating in my head a simple image editor. I
actually started prototyping is some time ago in Java, but am liking
Python more and more. My editor will be nowhere near the level of Gimp/
Photoshop, but I do need fast pixel level control and display. For
instance, that means no automatic anti-aliasing and that I will be
implementing my own line drawing algorithms.

I've got the high level architectual aspects of my program down, but
am stuck on what graphics API to use. I want a canvas area of
adjustable size which users can draw on with as little lag as
possible. The canvas area will be composed of layers (i.e. I require
an alpha channel) and I need to be able to zoom in and out of it (zoom
levels will be at fixed intervals, so this can be simulated if need
be.)

I started looking at PyGame but realize that I need to integrate a GUI
into the whole thing (or integrate the image into the GUI rather) and
I didn't see a straightforward way to do that. Of course, I don't even
know if PyGame is the right API for the job anyways :P

Any thoughts or ideas that could help me get started? Thanks!

[Ivan Illarionov]

On Mar 18, 4:36 am, dave <man...@gmail.c omwrote:

Hi All. I've been formulating in my head a simple image editor. I
actually started prototyping is some time ago in Java, but am liking
Python more and more. My editor will be nowhere near the level of Gimp/
Photoshop, but I do need fast pixel level control and display. For
instance, that means no automatic anti-aliasing and that I will be
implementing my own line drawing algorithms.

I've got the high level architectual aspects of my program down, but
am stuck on what graphics API to use. I want a canvas area of
adjustable size which users can draw on with as little lag as
possible. The canvas area will be composed of layers (i.e. I require
an alpha channel) and I need to be able to zoom in and out of it (zoom
levels will be at fixed intervals, so this can be simulated if need
be.)

I started looking at PyGame but realize that I need to integrate a GUI
into the whole thing (or integrate the image into the GUI rather) and
I didn't see a straightforward way to do that. Of course, I don't even
know if PyGame is the right API for the job anyways :P

Any thoughts or ideas that could help me get started? Thanks!

Look at the PIL source code for reference and implement your own C
extensions for drawing and image manipulation. Or write your app on
top of PIL. Any GUI toolkit will work if you find the low-level access
to their image memory buffers. PyGame is for multimedia applications,
you probably need Tkinter, Qt, wx or GTK.

And as long as you need such low-level things as custom drawing and
anti-aliasing your API is plain old C malloc's, free's and raw memory
addresses.

--
Ivan

[Miki]

Hello Dave,

Hi All. I've been formulating in my head a simple image editor. I
actually started prototyping is some time ago in Java, but am liking
Python more and more. My editor will be nowhere near the level of Gimp/
Photoshop, but I do need fast pixel level control and display. For
instance, that means no automatic anti-aliasing and that I will be
implementing my own line drawing algorithms.

I've got the high level architectual aspects of my program down, but
am stuck on what graphics API to use. I want a canvas area of
adjustable size which users can draw on with as little lag as
possible. The canvas area will be composed of layers (i.e. I require
an alpha channel) and I need to be able to zoom in and out of it (zoom
levels will be at fixed intervals, so this can be simulated if need
be.)

I started looking at PyGame but realize that I need to integrate a GUI
into the whole thing (or integrate the image *into the GUI rather) and
I didn't see a straightforward way to do that. Of course, I don't even
know if PyGame is the right API for the job anyways :P

Any thoughts or ideas that could help me get started? Thanks!

Apart from PIL, some other options are:
1. Most GUI frameworks (wxPython, PyQT, ...) give you a canvas object
you can draw on
2. A bit of an overkill, but you can use PyOpenGL
3. ImageMagick bindings? (http://www.imagemagick.org/script/api.php)

HTH,
--
Miki <mi*********@gm ail.com>
http://pythonwise.blogspot.com

[Ross Ridge]

Chris Mellon <ar*****@gmail. comwrote:

>OpenGL is totally unsuitable if the goal is to implement your own
pixel-level raster drawing.

Unfornately, any solution involving Python is likely to be unsuitable
if your goal is to set individual pixels one-by-one, and GDI would be no
better than OpenGL here. The overhead of calling some sort of putpixel()
function over and over will domininate everything else.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.u waterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[dave]

First I want to say thank you all for your timely replies. This is all
good food for thought. I've been programming more many years, but fast
graphics rendering is new territory for me.

I'm hoping to fine something like a buffer_blit, where I can set all
the pixels to change using basic operators, blit them all at once to a
pixel buffer, then swap the visible buffer. Ideally it will only
change the region of the pixel buffer that needs changing.

Because I want layers, I would like to take advantage wherever
possible of the available hardware features. I.E. ideally I am hoping
that the layers can be textures in memory that get composited in
hardware onto the screen. Maybe this is wishful thinking though?

I'm also thinking that maybe I can reduce the number of active layers
from N down to 3 - the active layer, the layers below it, and the
layers above it. Obviously only the active layer needs any sort of
sprite-like animations and it on this layer than response time is most
important. Having to layer the top layers ontop of it may also play a
factor but, as I suggested, I can merge them all together in one time
and then use the merged result to layer on top of the active layer.

I'm a little nervous about going the C/C++ route. It's been a few
years since I used them, I'm new to Python, and jumping into coding
Python extensions with C/C++ is not particularly palatable (though
I'll do it if I have to.)

Any GUI toolkit will work if you find the low-level access
to their image memory buffers.

That's another new step for me. Any ideas where to start? Thanks!

[Ivan Illarionov]

On Mar 19, 2:33 am, dave <man...@gmail.c omwrote:

First I want to say thank you all for your timely replies. This is all
good food for thought. I've been programming more many years, but fast
graphics rendering is new territory for me.

I'm hoping to fine something like a buffer_blit, where I can set all
the pixels to change using basic operators, blit them all at once to a
pixel buffer, then swap the visible buffer. Ideally it will only
change the region of the pixel buffer that needs changing.

Because I want layers, I would like to take advantage wherever
possible of the available hardware features. I.E. ideally I am hoping
that the layers can be textures in memory that get composited in
hardware onto the screen. Maybe this is wishful thinking though?

I'm also thinking that maybe I can reduce the number of active layers
from N down to 3 - the active layer, the layers below it, and the
layers above it. Obviously only the active layer needs any sort of
sprite-like animations and it on this layer than response time is most
important. Having to layer the top layers ontop of it may also play a
factor but, as I suggested, I can merge them all together in one time
and then use the merged result to layer on top of the active layer.

I'm a little nervous about going the C/C++ route. It's been a few
years since I used them, I'm new to Python, and jumping into coding
Python extensions with C/C++ is not particularly palatable (though
I'll do it if I have to.)

Any GUI toolkit will work if you find the low-level access
to their image memory buffers.

That's another new step for me. Any ideas where to start? Thanks!

Some reading on fast 2d graphics:
chapters 35-42 from
http://www.byte.com/abrash/

and a lot of great stuff here:
http://tog.acm.org/GraphicsGems/

[Ivan Illarionov]

That's another new step for me. Any ideas where to start?

http://docs.python.org/ext/simpleExample.html

And look into the source of existing extensions. PIL and PyCairo are
the best in your situation.

[Peter Wang]

On Mar 18, 6:51 pm, Ivan Illarionov <ivan.illario.. [e-mail] e:

That's another new step for me. Any ideas where to start?

http://docs.python.org/ext/simpleExample.html

And look into the source of existing extensions. PIL and PyCairo are
the best in your situation.

You shouldn't be afraid of doing raster graphics in Python; you'll
just need to be familiar with Numpy. You can easily compose layers,
mask out operations to only happen on one channel, etc., and code it
all up in Python while getting C-level speed. The gotcha, if you use
PIL, is that you're going to have to use tostring() and fromstring()
to get the array data back and forth between numpy and PIL. An
alternative is to use openGL, as others have suggested, and blit into
a texture. If you use pyglet, for instance, you can use Andrew
Straw's pygarrayimage module to convert a numpy array directly into a
texture.

I wouldn't recommend Cairo for doing pixel-level ops, since it is a
vector graphics library.
-Peter