Converting png to jpg gives black background

It's an artifact of JPEGing.
JPEGs don't do transparency (as you know).
Manipulating a transparent PNG in some ways then flattening to a JPEG without defining an explicit 'matte' color has undefined results, generally derived from the binary encoding of the object. Some image processes are nice enough to define a useful default matte color, many are not. Either black or white (or sometimes grey or hot pink) are 'useful' to different folk at different times... so "undefined". Occasionally you may even get white noise there.

Anyway. The obvious fix is there in your imagecache_actions toolbox - for exactly this purpose.
"Define canvas" will let you set a solid background for your image. If white is your choice, do white. Do that before converting format of course.
The 'Alpha Transparency' filter also had 'flatten transparency' (with color) as an option.

The UI form should have a note explaining all that for you ... Hm, not explicitly on the 'convert' action I see. But it is documented in the 'alpha transparency' action.

Hey

Sorry I don't think I understand here... I've been banging my head on this for a bit still not sure

I've got the following image-style

* Define canvas left:2 right:2 top:2 bottom:2 #ffffff under image
* Change file format Convert to: png
* Scale width 296
* Alpha Transparency (using flatten trick)

But it's weird cause when I change this to black it actually shows a black border. Do you think that's related to #1399740: Converting png to jpg gives black background

Sorry I meant #1063430: Change file format :: Doesn't change the file extension

Sorry I don't think I understand here what your problem is :)

The style you present results in the image with a white border and then scaled down. So if you change white to black you get a black border, so you describe hat you should get as a problem?

Note 1: You change to png format and then flatten out transparency. Seems a bit contradictory to me.

Note 2: You better first scale (down) and then add the border, otherwise the border might get halved (or even removed on very large images).

For anyone else running into this problem.

The GUI for this has a small "error". The Color field is pre-populated with a HEX value - say #000000. If you change this value to #FFFFFF the value is accepted. However if you look further down on the screen you'll see that the value # #FFFFFF is being used.

Upshot. Don't prefix your value with #. If you use FFFFFF everything works!

See my previous comment. GUI could be improved -> Define Canvas

Or at least do a check in the webform to see if the # is there and if it's not add it

#6: can you create a separate issue for this? Your bug does not seem to be related to the original post.

#2139091: # sign before HEX in settings form breaks "Define canvas" action - I've tried to fix issue mentioned in #6.

I guess this will be solved by now. Feel free to reopen if not adding any additional info possible.

This issue still exists in my build - and defining any image layer actions earlier in the stack (alpha flatten, or define canvas + overlay source) does not solve the issue. I believe the maintainers should reconsider this default behavior for converting PNG or GIF to jpg for a few reasons -

1. The current behavior is the minority use case for what a user would want. There is really no workflow in any image editing routines where a PNG converted to a JPG should have a black background. This is a use case that maybe 1 in 1000 users would want.
2. The current behavior requires additional config that may not work in all environments
3. The current behavior requires additional operations and excessive CPU load to get the desired default by a majority of site implementers.
4. If we change the default behavior for flattening the JPG onto a white background, and a user wishes to have black or some other color, they can always opt-in to this and add a composite operation higher up in the stack

I am not adding a formal patch, because I only use imagemagick as a toolkit so I'm not sure how to implement this so it works with GD. However, as I think most developers will want this as the default behavior - here is my code addition to implement this as a default behavior in the module. This could be added onto and turned into a formal patch by the community if someone wants to take a stab at abstracting it to what the toolkit requirements are.

Added into function coloractions_convert_effect before the image_toolkit_invoke function.

  if ($data['format'] == 'image/jpeg') {
    $image->ops[] = '-background white -flatten';
  }

re #12

1) The current behavior is that the alpha channel is removed, ie, the color that each pixel had (but was not shown due to being transparent is taken. So that is: we do nothing special, thus also not creating a black background.

2) Can you explain? What config?

3) The additional operation (define canvas) is about the same as what you suggest but user defined. So, I don't see this excessive CPU usage.

4) To not define additional operations (define white background under a user defined blue or black or whatever background) we prefer that the user always specifies the background and we do nothing. We could merge this, but we prefer basic/atomic effects, the style is there for assembling these atomic operations.