ImageAPI GD2 6.x-1.5 ignores crop background color setting

which type of image are you rotating? and is there transparency?

I got the same problem on my JPG images. I used "crop" and "rotate." It added black background to me ignoring my configs.

I'm using ImageAPI 6.x-1.5 and ImageCache 6.x-2.0-beta8

Same here:

Deprecated Scale     width: 130px, height: 130px, fit: Inside dimensions
Crop                 width: 130px, height: 130px, xoffset: center, yoffset: center

I've set the Crop background on admin/settings/imageapi/config to FFFFFF and it's still resulting in black bars.

I'm using 8-bit png images with no transparency.

The only place I can see imageapi_crop_background is as the form key and in the default value: variable_get('imageapi_crop_background', ''). Where should this be used?

there's actually two bugs. image api has an incorrect parameter name on imageapi_gd_image_rotate() and then imagecache has some issues passing the background color.

the imageapi_crop_background variable that psynaptic points out needs to be removed since it's old cruff.

the attached patch takes care of the imageapi side. i'll open an imagecache issue for the rest.

Committed to DRUPAL-5 and DRUPAL-6--1.

Your patch takes care of the rotate case, but what about the crop case?
When you crop an image to be bigger than it's current size, black padding will appear.
We need this to be transparent or white.

that's a good point. but since imageapi is in core in 7 i think we should open this as a new core issue and get the fix in there and then backport into imageapi.

Update: the following hack gets rid of 1 of the 2 black bars that appear.

Inspired by the following comment here: http://ca2.php.net/imagecreatetruecolor

If you want to place an image on a larger canvas you've previously created with imagecreatetruecolor(), but you don't want the default black background to surround it: use
imagefill() AFTER imagecopyresampled(). I have no idea why this should be the case, but it works!

Index: site/sites/all/modules/imageapi/imageapi_gd.module
===================================================================
--- site/sites/all/modules/imageapi/imageapi_gd.module  (revision 2889)
+++ site/sites/all/modules/imageapi/imageapi_gd.module  (working copy)
@@ -107,6 +107,7 @@
   if (!imagecopyresampled($res, $image->resource, 0, 0, $x, $y, $width, $height, $width, $height)) {
     return FALSE;
   }
+  imagefill($res, 0, 0, imagecolorallocate($res, 255, 255, 255));

   // Destroy the original image and return the modified image.
   imagedestroy($image->resource);

I just opened #437702: Separate background color and transparency options, add them to crops that enlarge the canvas so lets take it up over there then open a new issue to backport the fix here.

Hi,

I don't know if it helps but I'm using ImageAPI 6.x-1.3 and ImageCache 6.x-2.0-beta8 and when I crop with oversize, it properly uses the background color I've setup in Administer>Site Configuration>ImageAPI / Configure

Since ImageAPI 6.x-1.4 and up to 1.6, it doesn't work anymore (always uses black) so I reverted to 1.3

Also I think it's since 1.6, but the "Crop Background" color setup is not here anymore?

#437702: Separate background color and transparency options, add them to crops that enlarge the canvas is tricky... i need to rope dman into helping me fix it.

This was a beast for me as well, and I finally figured out a hack to get rid of the black bar on both sides, using the idea from comment #8, while waiting for it be backported:

Index: site/sites/all/modules/imageapi/imageapi_gd.module
===================================================================
--- site/sites/all/modules/imageapi/imageapi_gd.module  (revision 2889)
+++ site/sites/all/modules/imageapi/imageapi_gd.module  (working copy)
@@ -107,6 +107,7 @@
   if (!imagecopyresampled($res, $image->resource, 0, 0, $x, $y, $width, $height, $width, $height)) {
     return FALSE;
   }
+  imagefill($res, 0, 0, imagecolorallocate($res, 255, 255, 255));
+  $new = imageapi_gd_create_tmp($image, $width, $height);
+  imagecopy($new, $res, 0, 0, 0, 0, ($width + $x), ($height + $y));
+  $res = $new;

   // Destroy the original image and return the modified image.
   imagedestroy($image->resource);

that seems illogical. so you fill the cloned image, then allocate a new image, then copy over it?

It's not pretty, but it was the only way I could find to get rid of the black bar that gets created from the crop. You would think that filling the cloned image would get rid of both black bars, but it only gets rid of the one on the left, hence the need for the second copy. Go figure...

Had a similar issue that a background from a gif image would be displayed as purple instead of white.
With ImageAPI 6.x-1.6 it showed a partially white background with black sidebars.
Using patch in #13, the black sidebars went away.

Note that the left sidebar is white and not transparent! The right sidebar is transparent.
Don't know why it shows a partially white background with purple spots, propably because of some loss of quality/colors from gif to png?

Just checked with ImageAPI 6x-1.5 again with ImageCache 2.0-beta10
Setting nothing for background in settings for ImageAPI resulted in a better result than using ImageAPI 6.x-1.6 + ImageCache 2.0-beta10 + patch #13.
The image still had a partially white background with purple spots but now the left AND right sidebar were transparent.

Hope this helps.

Had another go at this.
Using tux.gif and an image style of Scale and crop 150x150 I get a strange background. See tux_without_patch.gif

Almost have a patch working for gifs, it's just displaying a strange glow it shouldn't.

See tux_with_patch.gif for the final result.

subscribe