Problem with PNG from tinypng
We recently bought the photoshop plugin from https://tinypng.com/
It really rocks to compress png (more than 70% savings) but those png does not seems to play well with php GD: the transparency becomes 'pixelized'

Anybody has a clue to why ? (I would guess color palette, but I am no png expert)
I could be completely wrong but here's my understanding:
Tinypng outputs an 8-bit indexed png with alpha transparency, whereas most transparent pngs on the web are 24-bit, non-indexed.
Your image on the right is a result of alpha transparency being ditched in favour of indexed transparency - the 'pixelation' is occuring on the boundary between fully transparent and semi-transparent areas of the image, as indexed transparency literally makes one indexed colour transparent.
GD does support alpha transparency using the imagesavealpha function; my guess is that JIT doesn't use this. Perhaps because, as php.net notes, 'not all browsers support alpha transparency'.
Hope that sheds some light, even if it doesn't lead you to a solution!
Wow @johnpuddephatt thanks for the explanation, I'll dig deeper than!
As per php's doc: You have to unset alphablending (imagealphablending($im, false)), to use it.
I hope we are not using it !!
So I've made it worked (THANKS!!) but the filesize explodes when compared to what tinypng gives...
I'll reopen this since I may have found a way to make it work.
Jit image already uses imagesavealpha()
Adding those two line after this one seems to do the trick:
imagealphablending($dst, false);
imagesavealpha($dst, true);
Note: (those two calls are already present in the else clause. I wonder why they are not always called (@designermonkey @brendo ?)
I'll test more on this, but I think we found a winner...
Note: (those two calls are already present in the else clause. I wonder why they are not always called (@designermonkey @brendo ?)
I don't think it would be on purpose...
I don't think it would be on purpose...
So it would be safe to always call them ?
I'm not too sure, this isn't a strength of mine. Best case would be to add it and then test with a couple of different scenarios such as:
- resizing
- cropping
- providing a fallback background
- using a transparent png
- using a jpg
- using a non transparent png
If we can do before/after comparisons on the above, then it's fair to say it's safe to add this function all the time.
Will do.
When testing the current integration branch, I also experienced strange issues with PNGs. I am not entirely sure if these were related to your issue, @nitriques. But I will be happy to test your solution with my setup, if you tell me where to put these lines. (The link you posted goes to line number 2, which can't be true.)
The link you posted goes to line number 2, which can't be true.
Here's a permalink
BTW, I have "unit" tests on that thing, I'll share it ASAP.
BTW, I have "unit" tests on that thing, I'll share it ASAP.
👍
OMG, GitHub Spam!
@michael-e if u think its spam i will delete
Yes, please delete it. It has nothing to do with this thread.
ok thanks for guiding.deleting
On Tue, Feb 14, 2017 at 8:06 PM, michael-e [email protected] wrote:
Yes, please delete it. It has nothing to do with this thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/symphonycms/jit_image_manipulation/issues/99#issuecomment-279723746, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvFGVet9yhX-7iHJeTAc3mrIKsf9znlks5rcbv2gaJpZM4DPlAd .
Thanks! Feel free to open a new issue if you intend to discuss a proposal for JIT.