New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gdImageCrop neglecting transparency? #432

Closed
y-a-v-a opened this Issue Jan 31, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@y-a-v-a

y-a-v-a commented Jan 31, 2018

Hi,
I'm the maintainer of node-gd, the NodeJS bindings to libgd. Someone came with the following issue in the node-gd repository, and after some research in libgd, I think it is a bug in libgd. In short: trying to crop a source image with transparency results in a cropped destination image with all black for where the source image was transparent.

According to https://github.com/libgd/libgd/blob/master/src/gd_crop.c#L53 gdImageCreateTrueColor is being called which, as stated here https://github.com/libgd/libgd/blob/master/src/gd.c#L264 will always be filled with black by default.

So the destination image of gdImageCrop is filled with black by default. When gdImageCopy is called to crop the source onto the destination, it nicely blends the source color onto the destination since, quote: "alpha blending is now on by default". As per https://github.com/libgd/libgd/blob/master/src/gd.c#L341. And programatically you're unable to modify the destination (i.e. cropped image) before the source is copied upon it.

So the solution would be, as far as my knowledge of C goes, which is effectively very little, to be honest, to set the alphaBlendingFlag of the destination image for gdImageCrop to 0 before copying the source to it.

Issue in node-gd repo: y-a-v-a/node-gd#60

Cheers,
Vincent

@cmb69

This comment has been minimized.

Contributor

cmb69 commented Jan 31, 2018

Thanks for reporting this issue, and coming up with a solution! The only question that remains is whether we should reset the alphaBlendingFlag (BTW, a misnomer since it actually stores a gdEffect*) after gdImageCopy(), or not. Probably we should.

@cmb69 cmb69 added the bug label Jan 31, 2018

@cmb69

This comment has been minimized.

Contributor

cmb69 commented Feb 1, 2018

Interesting, PHP's bundled libgd doesn't seem to be affected by this issue, because the implementation was "slightly" different from the start: libgd vs. PHP.

@pierrejoye Is there any particular reason why the implementations differ so much? Which implementation would be preferable?

PS: Solved with php/php-src@b309f64

@cmb69 cmb69 closed this in a15130c Feb 2, 2018

@cmb69 cmb69 added this to the GD 2.2.6 milestone Feb 2, 2018

cmb69 added a commit that referenced this issue Feb 2, 2018

Fix #432: gdImageCrop neglecting transparency
When using `gdImageCopy()` for image cropping, we have to make sure
that it doesn't use alpha blending (the current default), but rather
`gdEffectReplace`.  We reset the `alphaBlendingFlag` after finishing
the copy operation.

(cherry picked from commit a15130c)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment