PNG to JPG - Background Transparency

[Chris Ryan]

Hi everyone,

I am getting an unwanted background effect when converting PNG to JPG and was wondering if anyone has come across a way to get a better result? It seems related to the transparent background on a PNG and then how ImageMagick or GD is processing that background effect for the JPG preview.

If the attached images aren't visible within the group discussion, I basically get a yellow/tan distorted effect surrounding the outline of the image.

Thanks,
Chris

[Tom Gleason]

This won't fix your problem but it may help in finding a solution:

convert your.png -background white -flatten test.jpg

This command produces better results I think.

> --
> You received this message because you are subscribed to the Google Groups
> "ResourceSpace" group.
> To post to this group, send email to resour...@googlegroups.com.
> To unsubscribe from this group, send email to
> resourcespac...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/resourcespace?hl=en.
>

--
Tom Gleason, PHP Developer

Exploring ResourceSpace at:
http://resourcespace.blogspot.com

ResourceSpace Support Services
https://www.buildadam.com/muse2

[Tom Gleason]

[Chistophe]

Much better, thanks!

Now if I can my "image_alternatives" piece to work then I can pass
these additional parameters to handle the background.

-Chris

>  test.jpg
> 94KViewDownload

[Jeff Harmon]

maybe for PNGs we should just resize and keep them in their native
format, since they're web ready? or if that's a bad idea for some
reason, we would need to honor the transparency, flatten against
checkerboard (different sizes for each preview size so the
checkerboards were visible), then convert to JPEG.

- Jeff

On Mar 23, 10:18 am, Tom Gleason <t...@buildadam.com> wrote:

[Mike]

Hi Tom,

Where do I add this code to get around the PNG transparency issue? I"m
having the same problem.

Mike

[Jeff Harmon]

it's not as simple as adding the line. you'd need to branch on the
PNG extension. also, the -alpha off switch is desirable for PSDs and
TIFFs, but not for GIFs and PNGs, and right now you can't make one
change without messing up the other set. you might consider funding
the development to prioritize it in the queue if it's beyond your
programming abilities.

- Jeff

[Christopher May]

I am having the same issue - all my thumbnails of PNG's in resource space look like poo. Can we not just display the .png as the thumbnail? or make better thumbs? Surely other have complained about this...

[Bill]

I would be having this issue with png uploads I was trying to find a fix or see if any one had a code change. Has this been updated/fixed?

[Jeff Harmon]

Nothing has changed, sorry. 

Jeff

--

Jeff Harmon

Chief Executive Officer

Colorhythm LLC

http://www.colorhythm.com

Main Office:  +1 415-399-9921

Fax: +1 253-399-9928

Mobile:  +1 510-710-9590

jha...@colorhythm.com

--

You received this message because you are subscribed to the Google Groups "ResourceSpace" group.

To unsubscribe from this group and stop receiving emails from it, send an email to resourcespac...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bill]

Ok, so I have made a few changes. Let me know if you see a problem with this, but I did get the png to create and good thumbnail. This is still creating a jpg file, as I would agree in just creating a smaller png file would be good.

I did the following.

image_processing.php

original  (line ~660):

if (isset($imagemagick_path))

changed to:

if (isset($imagemagick_path) && $extension!="png") // Skip over the png as we are getting added artifacts on the previews. PNG will use the GD library.

After making this change I no loger had artifacts in the previews, but the background of the created images were black. I need them to be white:

Directly after (line ~710)

$target = imagecreatetruecolor($tw,$th);

I added two lines:

$bgColor = imagecolorallocate($target,255,255,255); // Change the background from black to white

ImageFillToBorder($target, 0, 0, $bgColor, $bgColor);

This appears to work ok as any image that has a back ground color will replace the white. So I am good there.  

The result that I get after this change, a png file with a transparent background uploaded to RS has a jpg thumb image created with a white background. The png source stays intact upon download.

Please let me know if these changes would benefit anyone else, but I would like to have or see a fix at the core level, so I would not have to alter the file when updating. 

[Bill]

I updated to the latest version and started having this png issue again. I was able to make the above changes and things seem to work for me. Would this be a useful edit to apply to the core? or is there something else that I am missing to help with the transparency?

[Joe Song]

I found out that the fix Bill discovered doesn't work with watermarks. Apparently, watermarked images are only created when the previews are created via ImageMagick, so with that fix the watermarked images are not created and just show up as broken images. The underlying problem is that the IM converter doesn't ignore hidden pixel data when converting a png to a jpg. But it will ignore it when flattening and storing the result as another png. So, instead of the above workaround, the code needs to first flatten the png and create a copy with a white background, then create the jpg previews from that copy. 

To do this, we need to run the IM copy command. The path to the IM convert tool is not found until the loop used to make the various sizes (which seems inefficient since it then re-finds the path each time). We're going to pull it up to the top of the create_previews_using_im function and out of the loop. Move the following lines from approximately line 840 of image_processing.php

# Locate imagemagick.

$convert_fullpath = get_utility_path("im-convert");

if ($convert_fullpath==false) {exit("Could not find ImageMagick 'convert' utility at location '$imagemagick_path'.");}

and insert them just inside the conditional at line 767 so that it looks like this:

if (isset($imagemagick_path))

{

# Locate imagemagick.

        $convert_fullpath = get_utility_path("im-convert");

        if ($convert_fullpath==false) {exit("Could not find ImageMagick 'convert' utility at location '$imagemagick_path'.");}

Then, after we get the file path to the original, if the file is a png, create a flattened copy (this goes right after and outside the conditional that directly follows the above insertion and opens with "if($previewbased)":

// flatten pngs only

if ($extension === 'png') {

// create a new file name to copy to so we preserve the original

$flattened_file = preg_replace('/\.png$/i', '_flattened.png', $file);

// build the IM command that will flatten the image ("-alpha remove -alpha off") with a white background ("-background white") 

$initial_png_command = $convert_fullpath . ' ' . $file . ' -background white  -alpha remove -alpha off ' . $flattened_file;

// run that command!

run_command($initial_png_command);

// for the rest of the thumbnail versions, base them off the flattened version

$file = $flattened_file;

}

The "-alpha remove" part requires ImageMagick 6.7.5, I believe. I've attached a txt file containing the whole create_previews_using_im function for those that just want teh codez. 

[Bill]

I updated to the latest version 6.0-5120 and started having this png issue again. I was able to make the changes posted here and things seem to work for me. Would this be a useful edit to apply to the core? or is there something else that I am missing to help with the transparency? We don’t use watermarks on our images, but I do think that some testing would need to done to fix this.

[buyi wen]

you can try this free online image converter to convert png to jpg keep transparent backgroud.