If I understand correctly, you export PNG files from Spine as an atlas, convert them to 8-bit with pngquant, then display them with spine-phaser.
The linked issue for pngquant says it uses PMA in its processing and it doesn't preserve colors for transparent pixels, which makes sense for a palette. Checking or unchecking Bleed should not matter, as it sounds like pngquant is going to premultiply. If you check Premultiplied alpha and pngquant premultiplies again, that will ruin your images. If pngquant has no way to tell it the PMA is already done then be sure not to give it PMA images.
I don't understand where green color comes from!
Mario I don't quite get why the pngquant author refuses to set the transparent color's palette entry to rgb(0, 0, 0).
Is the green coming from the 8-bit palette using green for transparent? That does seem odd, but the results would still be poor using black and alpha=0. The only reason non-PMA rendering looks reasonable is because Spine performs Bleed. To render without PMA, you'd need to perform bleed after pngquant. Here's some code to do that, but the result would be a 32-bit PNG, which isn't what you want. An 8-bit PNG can't be PMA (it uses a palette), so you'd need to PMA while loading the image data or in a shader. Performing bleed at runtime is harder and the rendering is worse, so I wouldn't do that -- use PMA like the image gods intended.
The WebGL "unpacking" is dividing the color by the alpha? That's crazy and never something you want, plus it will need to use some color (black?) when alpha is zero: now you have no "bleed" and non-PMA rendering will look bad. The image of the PMA unpacking looks pretty good, but the dark borders would indicate rendering is not done for PMA, or is done for PMA but the image is not PMA.
One more thing, if you are using 8-bit images, you should be able to load them into an 8-bit texture rather than using 32-bit textures (reducing runtime video memory usage). Then you'd need to do PMA in a shader. One problem at a time I suppose. 😉
