Not sure if there is a workaround when inputting a transparent PNG but generating a JPEG with your package. Let me know if you'd like to see an example or if this is a common problem. Thanks.
I have come across this issue too. Have you found any sensible ways to mitigate this?
Yep - try this:
Replace lines 283-286 in the Intervention Image source code (the first 4 lines of the modify method) with:
$image = imagecreatetruecolor($dst_w, $dst_h);
$white = imagecolorallocate($image, 255, 255, 255);
// preserve transparency
$transIndex = imagecolortransparent($this->resource, $white);
Only issue with this solution is that every time you do composer update/install it will revert the code back to original state. You can always fork the repo in the state you're happy with to a private repository and then load the dependency on the forked Intervention repo.
Hope that helps.
You can also create a new image with your desire background-color and insert the transparent image:
$canvas = Image::canvas(300, 200, 'ffffff');
$canvas->insert('transparent.png');
$canvas->save('white_bg.jpg');
I have come across this problem. If I upload a PNG with a transparent background, PHP puts it in the /tmp folder, with a random temp file name like /tmp/phpdk39d or whatever. If you do this:
$image = Image::make('/tmp/phpdk39d')->save();
Then it overwrites the tmp file. However, the image will now have a black background instead of transparent like the original.
The temporary solution (until Intervention dev's figure out the underlying problem), is to save the file to a spot not in the /tmp directory. For example, if I do this:
$image = Image::make('/tmp/phpdk39d')->save('mynewfile.png');
Then the image is saved into my public directory of my website and it does have the transparent background like the original.
Actually I want to amend my previous reply. I have discovered that the problem of the black background comes if you try to save a file without the .png extension. It then ends up with a black background.
// Results in black background image
$image = Image::make('/tmp/phpdk39d')->save();
// Results in black background image
$image = Image::make('/tmp/phpdk39d')->save('myfile');
// Correct transparent background
$image = Image::make('/tmp/phpdk39d')->save('myfile.png');
I'm not sure why Intervention (or GD rather) is saving the file as a JPG or with the wrong MIME type or what... I would think it would be smart enough to read the mime type of the original file and then save it with that MIME type. Not sure. But I think the above is the proper workaround.
I think this is still a problem for people that want to convert PNG's to
JPEG's.
True but the jpeg format doesn't support transparency and doesn't have an alpha channel so transparency is impossible. To that end, one would always need to create a background on which to overlay the PNG onto.
Photoshop for example automatically places the image on a white canvas. Are you proposing that intervention/image performs the same operation automatically if it detects png to jpeg conversion?
It is currently possible to achieve that using the aforementioned suggestion by @olivervogel but the detection process is currently not offered. Comparison of mime types would currently be application specific but may be better as part of the library where the default canvas colour is a configurable option, ideally defaulting to white.
I think that's the expected behavior, that if a user is saving out to a
jpeg (largest use case) from any of the file formats that Intervention
supports, and if the input mime-type is gif or png, to automatically apply
a white background to the specified output canvas size (or default size). I
think setting a non-white background is an esoteric feature but if not too
time consuming to implement might be passed as an array of options, or if
easier an additional method.
I just updated the 2.0 branch. Now white is used as default background, when converting to non-transparent formats.
I switched a few hours ago to the new Intervention Image 2.0, which introduces a few changes in the api. Please make sure to take a look at the upgrade instructions.
I think the white background by default is better than the black, so good call there.
But how come when I open a png file (that does not have a png extension on the filename), and then save it, it saves it out as a JPG? Shouldn't Intervention know to save it back out as the original file type? That's how this whole black background thing came to light.
A very typical example of this is when you upload a file using a File input in a form. PHP typically puts it in the systems /tmp folder with a randomly generated EXTENSIONLESS filename, such as /tmp/phpd9fk33. It does not have an extension, but if you uploaded a PNG file, its still a PNG file. I would think Intervention would know that and save it back out as a PNG file when you simply do a ->save().
Thanks, this is greatly appreciated.
@Jakobud Is fixed in 6d250.
Remember that this is the 2.0 version, which comes with a few changes but supports GD and Imagick.
Ah excellent. 2.0 appears to be out of beta now, right?
I still get black background when I use $image->fit() method.
I use gd driver and this source image: http://www.pngall.com/donald-duck-png/download/15985 .
I am saving the image using:
$contents = (string) $image->encode('jpeg', 95);
Is it a regression bug or am I doing something wrong?
EDIT: $image->resize() does the same.
For anyone looking for a solution to fix this using fit(), this worked for me:
$image = Image::make('/path/to/source.png')->fit(250, 250);
Image::canvas($image->width(), $image->height(), 'ffffff')
->insert($image)
->save('/path/to/target.jpg', 70, 'jpg');
Most helpful comment
I still get black background when I use
$image->fit()method.I use
gddriver and this source image: http://www.pngall.com/donald-duck-png/download/15985 .I am saving the image using:
Is it a regression bug or am I doing something wrong?
EDIT:
$image->resize()does the same.