Issues porting PHP/GD wrapper to Imagick

Question

I\'ve recently discovered that Imagick can support color profiles and thus produce images of better quality compared to GD (see this question / answer for more details), so

Answer 1

There are a number of reasons why your PNG images may be increasing in size, the most obvious one that you will run into is GM/IM's inability to convey transparency as a tRNS chunk (basically boolean transparency for PNG images). Unfortunately the maintainers of GraphicsMagick and ImageMagick have not implemented this feature yet. I exchanged emails with them so I know this for sure.

I know you don't want to use external tools but trust me you do. Image/GraphicsMagick are really bad at compressing PNG images. The solution I am using is, use GraphicsMagick to manipulate the image and also check if the image contains transparent pixels, if it does contain transparent pixels then run OptiPNG on the image. OptiPNG will see that transparency can be conveyed as a tRNS chunk and act accordingly. Actually you should run OptiPNG on all PNG images after using Image/GraphicsMagick because I have found that you can achieve much greater compression. You can also save space by turning dithering off and by using the YUV color space.

As for GM reducing the size of images better than IM, you should know that GM by default uses an 8 bit color space when color reducing images while ImageMagick by default uses 16 bits. This is why GM is so much faster than IM when color reducing images to a value over 255 colors. Maybe you should check the number of colors in each image after compression to confirm.

Answer 2

You can use optipng (another PNG command-line tool) to optimize the size of your PNG files.

Answer 3

As there is not much support for ICM in browsers the profiles are essentially a waste of bandwidth. Thus if your images are in sRGB you can safely trash the profile, otherwise it is better to convert an image into sRGB and trash its profile afterwards.

The reason for removing a profile of sRGB images is that sRGB is effectively a standard on the Internet, on computers, and on printers, and even Firefox applies sRGB color profile to untagged images.

There is another reason for removing all profiles altogether, thou I'm not sure if it applies to your case: if you're planning to mix images with embedded profiles with other profile-less images, e.g. GIF images, which cannot contain a profile by definition, you'll end up with a messy result on an ICC-enabled browser. It'll render some images as per their embedded color space and other with a some other color profile, which leads to a situation in which you'll see a boundary between an image with an embedded ICC profile with a solid background color adjoining other profile-less image with the same color background color. Even if you manage to get a profile for every image on your page, there are a lot of users who use ancient ICC-disabled browsers.

Bottom line: color profiles are evil. Only use them if you actually need them.

What I said is right only if you target your site for a widest audience possible. Otherwise YMMV.

Answer 4

Im not sure if you still need an answer but I have been writing an image processing lib that wraps GD and Imagick so I have encountered some of your issues.

2 - Compressing Output Formats (Namely JPEG and PNG)

ImageMagick does not provide compression for PNG for the simple fact that PNG is a lossless format unlike JPEG which is a "lossy" format. I'd go as far as say that ImageMagick got this one correctly.

Just drop the the option to compress in PNG and just provide a sane default for imagepng in GD.

3 - Image Convolutions

Just loop on each pixels using the getPixelIterator and do a manual convolution. Wikipedia's has a good article about this with pseudo-code.

5 - Opening Remote Images

You can open the image separately and passed it to Imagick

$handle = fopen('http://example.com/foo.jpg', 'rb');
$img = new Imagick();
$img->readImageFile($handle);