ImageAPI GD2 6.x-1.5 ignores crop background color setting
vaartio - April 3, 2009 - 14:57
| Project: | ImageAPI |
| Version: | 6.x-1.5 |
| Component: | ImageAPI GD |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
ImageAPI GD2 generates always black background color in spite of the crop background setting. Tested with GD Library bundled (2.0.34 compatible).
#1
which type of image are you rotating? and is there transparency?
#2
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
#3
Same here:
Deprecated Scale width: 130px, height: 130px, fit: Inside dimensionsCrop 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_backgroundis as the form key and in the default value:variable_get('imageapi_crop_background', ''). Where should this be used?#4
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.
#5
Committed to DRUPAL-5 and DRUPAL-6--1.
#6
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.
#7
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.
#8
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
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);
#9
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.
#10
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?
#11
Automatically closed -- issue fixed for 2 weeks with no activity.
#12
#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.
#13
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);
#14
that seems illogical. so you fill the cloned image, then allocate a new image, then copy over it?
#15
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...
#16
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?
#17
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.