[Melbourne-pm] Image Manipulation

[Scott Penrose]

Hey Guys

As part of my Gallery code I need a very minimal set of image  
manipulations.
It has been wisely suggested to me that it is not a good idea just to  
depend on something like Image::Magic. One reason for this is that  
some implementations of a Gallery back end (eg: Flickr) do all the  
work for you.

So I could have it that my implementations of a library (eg: my  
example Simple, which works purely on files and directories) could  
depend on the necessary code, eg: Image::Magick.

This is tricky though because it then means that the simplest of  
classes requires the most complicated code, and I would like to have  
the simple class, at least for testing.

A quick side track: For those of you who do not know, I am writing  
"Gallery::" (name yet to be confirmed) which is an abstract Gallery  
API that works with any backend. Think of it as the DBI for Galleries.

Then I was reading up on all of the library advantages and  
disadvantages.

Firstly, my requirements are fairly small, here is a simple list:

* resize - Resize an image, almost always scaled (proportional),  
mostly smaller

* height/width - I need it... get it for me.

* rotate - Only need to do CW/CCW 90 degree increments

* return objec handle (to library) - Nice to pass it back, since it  
already exists, eg: if the user wants to do more in the native library.

So then I went through as many of the CPAN libraries as I could, and  
here is a quick summary, mostly they include some code to do the  
resize as a sample. The braces on the right indicate the features it  
supports.

	Image::Magick (height/width, resize, object)
		
		my $im = Image::Magick->new;
		$im->Read(file=>$self->filehandle);
		$im->Scale(-geometry=>'250x250');

		# Note: Also returns height/width

	GD (height/width, resize, object)

		Ahhh too hard, use Image::Resize !

	Image::Resize - GD wrapper (height/width, resize, object)

		$image = Image::Resize->new('large.jpg');
		$gd = $image->resize(250, 250);

		# Note: Also returns height/width
		$gd->width(), $gd->height
		
	Imager (height/width, resize, object)

		$newimg = $img->copy();
		$newimg = $img->scale(xpixels=>400);
		$newimg = $img->scale(xpixels=>400, ypixels=>400);
		
	Image::Epeg - JPEG only, but very fast (height/width, resize)

		# Resize down only !
		# Can set commments

		my $epg = new Image::Epeg( "test.jpg" );
		$epg->resize( 150, 150, MAINTAIN_ASPECT_RATIO );
		$epg->write_file( "test_resized.jpg" );

	GFL::Image (height/width, resize, object)

		# Note: Very nice, but license issues (free, non-commercial)

		$im -> load("test.png");
		$im -> set( output => "jpeg", undolevel => 5);
		$im -> resize (320, 200);
		$im -> save("test.jpg");

	Image::Imlib (height/width, resize, object)

		my $image = Image::Imlib2->load("foo.png");
		$image2=$image->create_scaled_image(100,100);


	Image::Info (height/width)

		my $info = image_info("image.jpg");
		my($w, $h) = dim($info);
		
	Image::Filter - another GD wrapper (not enough)


So... down to where to from here...

Let me say that one of my requirements is to have little to no  
requirements on large, especially C based (and thus compiled)  
external modules. Sure, they are required to do resize (I am not  
reinventing here) but if you don't resize, the library still works...

It seems I have a few options on where to go...

1) Hard code a few of the libraries in my own specific order. Try to  
load them, on failure fall through to one that works, or report that  
we need at least something. I note that many of the Gallery PHP  
applications use this approach, or a static list of which modules are  
loaded.

2) Write a wrapper class inside Gallery to deal with the above,  
allowing people to add a new backend without changing the other bits  
of code. This also implies that the user would have the ability to  
define which are supported/tried and in what order. This could speed  
things up on a busy site - but the library would still automatically  
try in case it doesn't know - allowing for a Zero configuration,  
working library.

3) Write an external wrapper - yet another abstraction, just for the  
most basic of functions - height, width, resize, rotate... Really the  
same as 2 but make it more usable outside. A little harder to write,  
new tests, module space etc.

My current thoughts is leaning in on 2.

3 worries me a little for two reasons: It is an unnecessary  
abstraction - using the Simple driver of Gallery you can already  
achieve what you would otherwise with 3, so just use Gallery (this is  
a sort of); where would it go, it seems that people writing modules  
such as "Image::Resize" have this sort of in mind, but have limited  
to one function, and one backend.

So... over to you my active perl development team and friends. What  
do you think I should do ?

Scooter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.pm.org/pipermail/melbourne-pm/attachments/20060429/b0ce5032/attachment.bin