Canvas background is applied only to resulting png but not jpeg. [#442114]

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.

Comment	File	Size	Author
#3	dsn-imagecache-issue.png	79.52 KB	soupp

Comments

Comment #1

dman commented 22 April 2009 at 22:40

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?

Comment #2

soupp commented 23 April 2009 at 16:33

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 :)

Comment #3

soupp commented 23 April 2009 at 13:12

Status	File	Size
new	dsn-imagecache-issue.png	79.52 KB

And here is the screenshot of the preset.

Comment #4

dman commented 23 April 2009 at 23:04

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 incanvasactions.inc:canvasactions_canvas2file_image()

  // crop both before processing to avoid unwanted processing.
  imagecache_crop_image($underlay, $crop_rules);
  imagecache_crop_image($image, $crop_rules);

  // 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.