JImage: adding imagemagick support

[Nils Rückmann]

Hi,

is there any purpose to add imagemagick capabilities to Jimage ?

[Chraneco]

Hi,

I also thought about that already and had a look at the library.
Unfortunately it is based on GD at the moment. I think it would be
necessary to completely rewrite it in order to add other image
manipulation tools such as ImageMagick.

Regards
Chraneco

[Nils Rückmann]

We could also use JImage abstract and addign JImageGD and JimageIM or something ..
But first of all i would like to hear something about the need or current works which belongs to Jimage

[brian teeman]

Well imagemagik can do a lot of very cool things that gd cannot do. The downside is that it's traditionally been a resource hog so hosts were reluctant to install it. But having the option to use it would be great. I'm working on a site using the digital asset management tool from Resourcespace.org and if you go there you can start to see what Imagemagik can add.

[Chraneco]

Hi,

> But first of all i would like to hear something about the need or current
> works which belongs to Jimage

In our component the user can choose between GD and ImageMagick. So at
the moment we cannot use JImage because of that. I think it would be
great to have JImage abstract and extended for different image
manipulation tools.

Regards
Chraneco

[Nils Rückmann]

what's about the filters ? any idea how we colud implement these, or should the filters be part of JImageIM ?

[Azrul Rahim]

As JomSocial have a built-in photo manager, I thought I'd share my experience. Imagick support i believe is essential. From my personal experience, 2 things that makes imagick support critical.

1) imagick uses memory better. I've seen so many GD-based server that choked with large images. This almost hardly ever happen with imagick. I always insist on our user to enable imagick and almost all their GD memory problem goes away.

2) Performance and server load. I didn't have a hard-stats on this, but we noticed that imagick is noticeable quicker and are less taxing on the server.

Development-wise, I don't think we should allow user to choose which one to use. We should really just use imagick if they are available, otherwise revert back to GD.

As for the need for engine abstraction, it might be nice, but not entirely needed since there probably going to be only these 2 engine in foreseeable future. A simple functionality test (similar implementation in JFtp) i believe is sufficient.

[Ofer Cohen]

I've started to refactoring the jimage here: https://github.com/oc666/joomla-platform/tree/jimagemagick/libraries/joomla/image

First, I've made the image.php interface which all layers (gd, imagemagick) implements (see layers/imagegd.php). After it, implement image factory for controlling the image layer (auto would be one of the cool options to choose automatically the available one). Finally, I would implement the filter objects to be executed via the factory (depend on the layer supply).

I would be grateful if others would help with that including thoughts on better implementations or efforts have been done so far.

Ofer Cohen
Joomlics Anonymous Group

[Ofer Cohen]

And about the filters of imagemagick, you can check this:

http://php.net/manual/en/imagick.resizeimage.php
http://www.php.net/manual/en/imagick.constants.php#imagick.constants.filters

Ofer Cohen
Joomlics Anonymous Group

On 02/12/2012 11:25 AM, Nils Rückmann wrote:

[Ofer Cohen]

And about the filtering, you can check this:
http://www.php.net/manual/en/imagick.constants.php#imagick.constants.filters

Ofer Cohen

On 02/12/2012 11:25 AM, Nils Rückmann wrote: