Yes, Image::Magick is a real pig, because what it is is a bunch of filters and pipes (just like Net::PBM) but with a big interface/wrapper around it. By doing that, and making it as platform independent as possible, it's huge, and piggy.
Also, not all the modules are included, and you have to go hunting around for this part and that part, and by the time you are done, it may still not work!! Image::Magick is very, very hard to install. I've never been able to install it successfully. Nor have a lot of others.
There was a thread here about that.
By using Net::PBM you can install it in your user directory, on a shared server, or in the '../share' area on a dedicated box, and either just use the parts you want, or the whole thing. Because they are all filters, you can just load the ones you need. I've tried to rewrite the shell scripts that did part of the functionality in perl, so that they should be portable to NT/Windows.
It's sort of an "Image::Magick Lite".
Once the image gallery program is ready, I'll probably have a a script to delete the unused filters, to save more space. Most of the conversions are not necessary, for web/graphics use. At first I'm only supporting the major formats. I'll deal with additional formats by request, I guess.
If you can install anything via CPAN, then you should be able to install Net::PBM by yourself. I'm on Solaris, which is the "roughest" OS to get anything to compile on, and this compiled without a hitch.
Both Net::PBM and Image::Magick have gotten a new lease on life. Both have been moved more to the open source arena and group development. If Image::Magick is improved, I might try to support it. But it will still cause a lot of ISP's to refuse to install it due to it's intensive resource usage.
None of my graphics are "on the fly" when a user requests them. They are generated when the files are uploaded (thumbnails, etc), and only once. Then they are just served like any other file. The overall resource usage should be quite small, and spread out -- unlike a system that was using the graphics routines "on the fly". Diskspace is the cheapest resource of all, and the small extra overhead of thumbnail files far outweighs the negatives!
I tried on-the-fly graphics once, and without a dedicated machine to just do the graphics, optimized for just doing graphics, I found one graphics process consumed as much as 10x the resources as non-graphic cgi-processes. If you've watched how much CGI can eat into a system's performance, cut that by a factor of 10, and realize that it's not a linear measure. 5-10 graphics requests could kill a Unix box that would otherwise be able to handle 75-100 non-cgi-graphics requests. If you've got 30-40 simultaneous users on your site, that means each graphics request would knock of about 7 or 8 of them on average. If you get 5 graphics requests, that consumes almost the same amount of resources (CPU, RAM, Disk I/O) that those 30-40 users were using.
On a dedicated machine with a gigabyte of ram, you might be able to get away with 10 graphics requests and 20-30 users with optimized hardware, but on a shared server situation, no ISP would go for that!
Sorry for getting long, but everyone wants these programs to do everything, and the practical limitations are that they just can't. Even in the BBS days, the thumbnails on the fly (so you didn't have to make graphics catalogs) needed high-end machines, and more than one or two users out of 16 requesting them, and the machines slowed down to a crawl.
In a development environment, all this is well and good, and I can generate everything on the fly, dynamic sites that make 20-30 database requests to generate a single page of output, and it flies! Of course the program has a whole P3 with 500meg and optimized I/O to itself. The same program in a production environment would kill a server twice as powerul if 10 users ever got on at the same time!
Optimization and tradeoffs are the only way to play the game!
PUGDOGŪ Enterprises, Inc.
FAQ:
http://LinkSQL.com/FAQ Forum:
http://LinkSQL.com/forum