Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re: Pixel-based Plotting in Perl?

by mr_mischief (Monsignor)
on Sep 02, 2008 at 20:55 UTC ( #708600=note: print w/replies, xml ) Need Help??

in reply to Pixel-based Plotting in Perl?

There are a few options, none of which are AFAICT perfect for what you're wanting.

GD, GD::Simple and Image::Magick will let you work with graphics files and save them. Then you'll need something to display those files.

Tk, The GIMP (perhaps with Gimp::Fu managing it), a browser, Prima (particularly Prima::Image perhaps), wxWidgets (with Wx, or something could take care of the display.

Some of those graphics loaders and GUI toolkits let you draw point by point in them, too. See Prima::Drawable and Tk::Canvas.

You can also tie into SDL and OpenGL (perhaps OpenGL::Simple). Those will give you even more graphics control than you're probably looking to use. You can even use SDL n conjunction with OpenGL or WxWidgets in conjunction with OpenGL.

There are Gtk and Qt, which are the graphics toolkits for Gnome and KDE.

Perhaps you're looking for something like Graphics::Simple, which is much like what some languages close to the metal of their platforms used to handle. It's marked as alpha and uses GTK or Postscript back ends.

You don't really say whether you want to show the drawing in progress on the screen or to show the result. Some of these options only really fit well into the completed image work flow. Others work well with updating the graphics on screen as you add or change elements. SDL, OpenGL, Tk, Prima, Gtk, Qt, and Graphics::Simple seem to be among those.

Portability is another issue. Tk, SDL, OpenGL, Qt, and Gtk can be used on most platforms but require the relevant libraries to be there. Prima is an option in Perl, but the others have bindings for other languages.

Your main issue here is that Perl is widget/toolkit/canvas ambivalent. The dialect of Basic you mentioned was tied tightly to the nature of the computer that drew the pixels for it. Once you pick a way to display your pixels, your application will be tied to some library unless you go the extra mile to make a handle of them interchangeable back ends. (That would be a neat trick, and many people would appreciate a module that wrapped Qt, Gtk, Prima, Tk, and SDL's graphics with a unified API. I doubt you're interested in doing that much work on it, though).

Replies are listed 'Best First'.
Re^2: Pixel-based Plotting in Perl?
by Joost (Canon) on Sep 02, 2008 at 21:09 UTC
    Good list. Of all of them, GD is probably the easiest to get started with, the easiest to install and the documentation is quite good (though many of the others are more powerful and/or have better image quality).

    I would like to add a plug for Cairo: it has excellent image quality and can export to all kinds of file formats (and to Gnome/Gtk widgets, if you have Gtk2 installed).

Re^2: Pixel-based Plotting in Perl?
by pat_mc (Pilgrim) on Sep 02, 2008 at 21:21 UTC
    mr_mischief - Thanks for your comprehensive post which outlines a whole spectrum of options!

    Can I just ask a newbie question: How exactly does Perl handle the display of graphics? As far as I understand, essentially, I have a Perl programme determine the position, size and colour of a pixel. And then? What exactly is a canvas? Is it a separate programme with an API? ... Sorry, I am just new to this whole area.

    Thanks again and cheers -

      Perl itself has no concept of pixels or screens. All it can do is call on libraries that manage displays or abstractions of displays. Most current operating systems will also not allow direct access to the display anyway - usually a program requests a window, which may be a MS Windows type window with title bar, menu etc, or may take up the whole available screen as a drawable map of pixels.

      For many applications it's more useful to have the more abstract notion of a canvas, which usually means an area on which you can place a combination of vector (lines, curves, circles, polygons etc) and possibly bitmap primitives with varying levels op transparency, height (IOW place one primitive on top of another), rotations, scaling, translations and so on and let the canvas deal with rendering all those primitives to the screen/window or to some file format (and some file formats like postscript, pdf and svg can store the primitives directly, which is very useful for printing, since you can get a more or less unlimited resolution out of vector primitives)

      And this is all just 2D imaging. 3D rendering libraries can be a lot more complex. :-) See OpenGL.

        Thanks for this very good primer on the underlying concepts of 2D-image processing, Jost. It is much appreciated!
      Basically, Perl doesn't do graphics directly. In order to do so, it would need to be tied to the specifics of the host device. The language itself is more than sufficient to hold and manipulate the data structures involved, although in some complicated cases it might be a little slow.

      What is needed is a way to get the shape and color data (or pixel data) into hardware for it to be rendered. That's where these libraries come in.

      GD, ImageMagick, and Cairo take instructions about shapes, colors, lines, and such and put out graphics formats other systems already understand. They are libraries that are used by your application (C/C++ libraries with Perl wrappers in this case).

      Tk, Gtk, Qt, SDL, WxWidgets, and OpenGL are APIs for external libraries that are built to actually draw into the windows on various OSes. They each allow you to write to their API and they write to the Windows, X11, Cocoa, or whatever API on the actual OS and device. Each of them is a separate API apart from the others on the list except that a couple of them can use OpenGL as an intermediate back end. All of them AFAIK work on Windows and OS X as well as Linux, Irix, and Solaris. Tk, Gtk, Gtk2, Qt, and WxWidgets are "graphical toolkits". They're made for bringing applications to GUIs without having to write all the windowing code and such. SDL and OpenGL are more general graphics things. There are implementations of those for framebuffer devices and for windowed GUIs (I think Qt has a framebuffer backend for embedded devices, too).

      In order to just write to the pixels being shown, you'd have to have fairly direct (driver level or lower) access to the video subsystem. In a protected, multi-user OS that's a bad idea. That's why these libraries exist, aside from also making many things easier and more uniform than everyone reinventing their own wheels with incompatible hubs and tires. On a sufficiently single-user system with a smallish single-user OS, one could write to video memory or to the framebuffer device provided by the OS directly still today. The trick is finding such a device.

        That makes things much clearer for me, mr_mischief. Thanks so much for closing this gap in my understanding.

        As for libraries, I have to admit I am not completely familiar with the concept. My understanding is that they are units of code with well defined interfaces that perform certain complex actions. Is it helpful to think of them as Perl objects which get created by my Perl programme via suitable constructors and subsequently addressed via appropriate methods or subroutines? Or are they actual programmes started by my Perl programme that run in parallel to it and then interact with it at runtime?

        Thanks again in advance for clarifying.


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://708600]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (2)
As of 2022-05-21 10:27 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (76 votes). Check out past polls.