CGI Programming with Perl |
PerlMagick is another graphics module designed to be used online. It is based upon the ImageMagick library, which is available for many languages on many different platforms. The Perl module, Image::Magick, is often referred to as PerlMagick. ImageMagick was written by John Cristy; the Perl module was written by Kyle Shorter.
ImageMagick is very powerful and supports the following operations:
ImageMagick supports more than fifty different image file formats, including GIF, JPEG, PNG, TIFF, BMP, EPS, PDF, MPEG, PICT, PPM, and RGB.
ImageMagick allows you to convert between these formats.
ImageMagick can create thumbnails of images.
ImageMagick can perform all sorts of manipulations on images including blur, rotate, emboss, and normalize, just to name a few.
Like GD, you can add basic shapes and text to images in ImageMagick.
ImageMagick can merge multiple images.
ImageMagick supports file formats with multiple frames, such as animated GIFs.
ImageMagick also includes tools, such as display, for displaying and manipulating images interactively.
We won't cover all of these, of course. We'll look at how to convert between different formats as well as how to create an image using some of the advanced effects.
You can obtain the Image::Magick module from CPAN, but it requires that the ImageMagick library be installed already. You can get ImageMagick from the ImageMagick home page, http://www.wizards.dupont.com/cristy/. This page contains links to many resources, including pre-compiled binary distributions of ImageMagick for many operating systems, detailed build instructions if you choose to compile it yourself, and a detailed PDF manual.
Image::Magick is much more powerful than GD. It supports numerous file formats and allows many types of operations, while GD is optimized for a certain set of tasks and a single file format. However, this power comes at a price. Whereas the GD module has relatively low overhead and is quite efficient, the Image::Magick module may crash unless it has at least 80MB of memory, and for best performance at least 64MB should be real RAM (i.e., not virtual memory).
Image::Magick supports GIFs. However, support for LZW compression is not compiled into ImageMagick by default. This causes GIFs that are created by Image::Magick to be quite large. It is possible to enable LZW compression when building ImageMagick, but of course you should check with Unisys about licensing and/or contact an attorney before doing so. Refer to the ImageMagick build instructions for more information.
As we noted earlier, unfortunately not all browsers support PNGs. Let's see how we can use Image::Magick to convert a PNG to a GIF or a JPEG. In order to use an image in Image::Magick, you must read it from a file. According to the documentation, it should also accept input from a file handle, but as of the time this book was written, this feature is broken (it silently fails). We will thus write the output of GD to a temporary file and then read it back in to Image::Magick. Example 13-5 includes our earlier example, commute_pie.cgi , updated to output a JPEG instead unless the browser specifically states that it supports PNG files.
#!/usr/bin/perl -wT use strict; use CGI; use GD::Graph::pie; use Image::Magick; use POSIX qw( tmpnam ); use Fcntl; use constant TITLE => "Average Commute Time: Pie Chart"; my $q = new CGI; my $graph = new GD::Graph::pie( 300, 300 ); my @data = ( [ qw( Mon Tue Wed Thu Fri ) ], [ 33, 24, 23, 19, 21 ], [ 17, 15, 19, 15, 24 ], ); $graph->set( title => TITLE, '3d' => 0 ); my $gd_image = $graph->plot( \@data ); undef $graph; if ( grep $_ eq "image/png", $q->Accept ) print $q->header( -type => "image/png", -expires => "now" ); binmode STDOUT; print $gd_image->png; } else { print $q->header( -type => "image/jpeg", -expires => "now" ); binmode STDOUT; print_png2jpeg( $gd_image->png ); } # Takes PNG data, converts it to JPEG, and prints it sub print_png2jpeg { my $png_data = shift; my( $tmp_name, $status ); # Create temp file and write PNG to it do { $tmp_name = tmpnam( ); } until sysopen TMPFILE, $tmp_name, O_RDWR | O_CREAT | O_EXCL; END { unlink $tmp_name or die "Cannot remove $tmp_name: $!"; } binmode TMPFILE; print TMPFILE $png_data; seek TMPFILE, 0, 0; close TMPFILE; undef $png_data; # Read file into Image::Magick my $magick = new Image::Magick( format => "png" ); $status = $magick->Read( filename => $tmp_name ); warn "Error reading PNG input: $status" if $status; # Write file as JPEG to STDOUT $status = $magick->Write( "jpeg:-" ); warn "Error writing JPEG output: $status" if $status; }
We use a few more modules in this script, including Image::Magick, POSIX, and Fcntl. The latter two allow us to get a temporary filename. See Section 10.1.3, "Temporary Files". The only other change to the main body of our script is a check for the image/png media type in the browser's Accept header. If it exists, we send the PNG as is. Otherwise, we output a header for a JPEG and use the print_png2jpeg function to convert and output the image.
The print_png2jpeg function takes PNG image data, creates a named temporary file, and writes the PNG data to it. Then it closes the file and discards its copy of the PNG data in order to conserve a little extra memory. Then we create an Image::Magick object and read the PNG data from our temporary file and write it back out to STDOUT in JPEG format. Image::Magick uses the format:filename string for the Write method, and using - instead of filename indicates that it should write to STDOUT. We could output the data as a GIF by changing our output header and using the following Write command instead:
$status = $magick->Write( "gif:-" );
Image::Magick returns a status with every method call. Thus $status is set if an error occurs, which we log with the warn function.
There is a trade-off to not using PNG. Remember that a GIF produced by Image::Magick without LZW compression will be much larger than a typical GIF, and a JPEG may not capture sharp details such as straight lines and text found in a graph as accurately as a PNG.
If you look through the list of formats that Image::Magick supports, you will see PDF and PostScript listed among others. If GhostScript is present, Image::Magick can read and write to these formats, and it allows you to access individual pages.
The following code joins two separate PDF files:
my $magick = new Image::Magick( format => "pdf" ); $status = $magick->Read( "cover.pdf", "newsletter.pdf" ); warn "Read failed: $status" if $status; $status = $magick->Write( "pdf:combined.pdf" ); warn "Write failed: $status" if $status;
However, keep in mind that Image::Magick is an image manipulation tool. It can read PDF and PostScript using GhostScript, but it rasterizes these formats, converting any text and vector elements into images. Likewise, when it writes to these formats, it writes each page as an image encapsulated in PDF and PostScript formats.
Therefore, if you attempt to open a large PDF or PostScript file with Image::Magick, it will take a very long time as it rasterizes each page. If you then save this file, the result will have lost all of its text and vector information. It may look the same on the screen, but it will print much worse. The resulting file will likely be much larger, and text cannot be highlighted or searched because it has been converted to an image.
Typically, if you need to create a new image, you should use GD. It's smaller and more efficient. However, Image::Magick provides additional effects that GD does not support, such as blur. Let's take a look at Example 13-6, which contains a CGI script that uses some of Image::Magick's features to create a text banner with a drop shadow, as seen in Figure 13-12.
#!/usr/bin/perl -wT use strict; use CGI; use Image::Magick; use constant FONTS_DIR => "/usr/local/httpd/fonts"; my $q = new CGI; my $font = $q->param( "font" ) || 'cetus'; my $size = $q->param( "size" ) || 40; my $string = $q->param( "text" ) || 'Hello!'; my $color = $q->param( "color" ) || 'black'; $font =~ s/\W//g; $font = 'cetus' unless -e FONTS_DIR . "/$font.ttf"; my $image = new Image::Magick( size => '500x100' ); $image->Read( 'xc:white' ); $image->Annotate( font => "\@@{[ FONTS_DIR ]}/$font.ttf", pen => 'gray', pointsize => $size, gravity => 'Center', text => $string ); $image->Blur( 100 ); $image->Roll( "+5+5" ); $image->Annotate( font => "\@@{[ FONTS_DIR ]}/$font.ttf", pen => $color, pointsize => $size, gravity => 'Center', text => $string ); binmode STDOUT; print $q->header( "image/jpeg" ); $image->Write( "jpeg:-" );
This CGI script indirectly uses the FreeType library, which allows us to use TrueType fonts within our image. TrueType is a scalable font file format developed by Apple and Microsoft, and is supported natively on both the MacOS and Windows. As a result, we can pick and choose from the thousands of TrueType fonts freely available on the Internet to create our headlines. If you do not have FreeType, you cannot use TrueType fonts with Image::Magick; you can obtain FreeType from http://www.freetype.org/.
The first step we need to perform before we can use this CGI application is to obtain TrueType fonts and place them in the directory specified by the FONTS_DIR constant. The best way to locate font repositories is to use a search engine; search for "free AND TrueType AND fonts". If you're curious, the font we used to create a typewriter effect, in Figure 13-1, is Cetus, which is included with the GD::Text module.
Now let's look at the code. We accept four fields: font, size, text, and color, which govern how the banner image will be rendered. If we don't receive values for any of these fields, we set default values.
As you can see, we have no corresponding user interface (i.e., form) from which the user passes this information to the application. Instead, this application is intended to be used with the < IMG> tag, like so:
<IMG src="/books/1/64/1/html/2//cgi/shadow_text.cgi?font=cetus &size=40 &color=black &text=I%20Like%20CGI">
The query information above is aligned so you can see what fields the application accepts. Normally, you would pass the entire query information in one line. Since this application creates a JPEG image on the fly, we can use it to embed dynamic text banners in otherwise static HTML documents.
We use the font name, as passed to us, to find the font file in the FONTS_DIR directory. To be safe, we strip non-word characters and test for the existence of a font with that name in our FONTS_DIR directory, using the -e operator, before passing its full path to ImageMagick.
Now, we're ready to create the image. First, we create a new instance of the Image::Magick object, passing to it the image size of 500 × 100 pixels. Next, we use the Read method to create a canvas with a white background. Now, we're ready to draw the text banner onto the image. If you look back at Figure 13-12, you'll see a banner with a drop shadow. When we construct the image, we draw the drop shadow first, followed by the dark top text layer.
We use the Annotate method, with a number of arguments to render the gray drop shadow. The path to the font file requires a @ prefix. But, since Perl does not allow us to have a literal @ character within a double=quoted string, we have to escape it by preceding it with the \ character.
Once we've drawn the drop shadow, it's time to apply a blur effect by invoking the Blur method. This creates the effect that the text is floating underneath the solid layer of text. The Blur method requires a percentage value, and since we want a full blur, we choose a value of 100. A value greater than 100% produces an undesirable, washed out effect.
Our next step is to move the drop shadow horizontally and vertically a bit. We achieve this by calling the Roll method, and pass it the value of "+5+5"; right and down shift by five pixels. Now, we're ready to draw the solid top text. Again, we invoke the Annotate method to render the text, but this time around, we change the pen color to reflect the user's choice. We're done with the drawing and can send it to the browser.
Finally, we enable binmode , send a content type of image/jpeg , and call the Write method to send the JPEG image to the standard output stream.
13.4. Additional GD Modules | 14. Middleware and XML |
Copyright © 2001 O'Reilly & Associates. All rights reserved.