Canvas background is applied only to resulting png but not jpeg.
soupp - April 22, 2009 - 20:57
| Project: | Imagecache Actions |
| Version: | 6.x-1.5 |
| Component: | Canvas Actions Module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
Hey guys,
Not sure what/which module (imagecache / imageapi / imagecache_actions) bug it is but: canvas background is applied only to resulting png but not jpeg.
Here are a couple of examples:
http://www.drupalsites.net/weblink/bookworm-productions (the way it has to be but only with submitted png).
http://www.drupalsites.net/weblink/attune-solutions (just white background with submitted jpg, though bg color field left empty in settings).
Hm... puzzled.
#1
Um, what am I looking at here?
Are you using canvas to a background texture under the image?
Or are you setting the canvas background and expecting the image to get a fixed size but be a transparent jpeg?
transparent jpeg?
#2
Oh, right. The idea is to fill empty part of the image with background.
The compiled image size is 250x250 which should contain say 250x150 jpeg (resized in prev. imagecache action) + background to underlay empty 100px.
And of course there are no transparent jpegs, this part i know :)
#3
And here is the screenshot of the preset.
#4
Yes, I've been able to replicate.
It comes from a fairly recent change where I use imageapi_crop to handle the cases where a background image is bigger or smaller than the foreground.
Currently this can be avoided by commenting out one line in
canvasactions.inc:canvasactions_canvas2file_image()<?php// crop both before processing to avoid unwanted processing.
imagecache_crop_image($underlay, $crop_rules);
imagecache_crop_image($image, $crop_rules);
?>
<?php// crop both before processing to avoid unwanted processing.
imagecache_crop_image($underlay, $crop_rules);
// Actually this failes because imagecache_crop fills it with solid color when 'cropping' to a larger size.
#imagecache_crop_image($image, $crop_rules);
?>
the crop was there to avoid extra processing on the per-pixel algorithm. Assigning a huge background (which is the only way to avoid tiling) was meaning that even small pictures took ages to process.
I'll try to find another way that doesn't use imageapi_crop. Or get imageapi to respect transparency.
#5
dman, thank you for clarification and the magnificent module of course! I'll play with your hint on local, we'll see how it goes.