tinydeflate should support texture atlases with transparent backgrounds about cute_headers

[RandyGaul]

Yep looks like a bug with paletted images. Thank you very much for making the reproduction! I'll have this fixed soon enough and add you as a contributor :)

[RandyGaul]

Looks like the bug wasn't too hard to fix. That depalette code comes from Richard Mittons tigr library, and I don't think he ever bothered to support images saved with a tRNS chunk. But, since tiny images that have a palette can also save some space by placing alpha into a tRNS chunk, I suppose it makes sense to add some support for it.

Okay so here were some of my findings from RFC 2083:

For color type 3 (indexed color), the tRNS chunk contains a
series of one-byte alpha values, corresponding to entries in
the PLTE chunk:

	Alpha for palette index 0:  1 byte
	Alpha for palette index 1:  1 byte
	... etc ...

So I've updated the depalette function to use the tRNS chunk if one exists. Otherwise it the RFC suggests to do the old c ? 255 : 0 trick:

Even if the decoder author does not wish to implement true
compositing logic, it is simple to deal with images that contain
only zero and one alpha values.  (This is implicitly true for
grayscale and truecolor PNG files that use a tRNS chunk; for
indexed-color PNG files, it is easy to check whether tRNS contains
any values other than 0 and 255.)  In this simple case,
transparent pixels are replaced by the background color, while
others are unchanged.  If a decoder contains only this much
transparency capability, it should deal with a full alpha channel
by treating all nonzero alpha values as fully opaque; that is, do
not replace partially transparent pixels by the background.  This
approach will not yield very good results for images converted
from associated-alpha formats, but it's better than doing nothing.

[zacharycarter]

Not at all! The images might be an issue - as they're from http://oryxdesignlab.com/products/16-bit-sci-fi-tileset which is commercially licensed to my knowledge.

I created bindings for Nim to this library. I haven't put them up yet, as they're unfinished at the moment, but I just tried out your fix and everything seems to be working great! Thanks so much for the help!

[zacharycarter]

I guess it's a little more complicated than that? Seems each image is saved with a white background as well, even if the original image has a transparent BG?

[RandyGaul]

Here's the white default. And here is the memcpy over the white default with each individual image.

In PNG pixels are stored in DEFLATE format, so there's called to inflate them here. I don't think it's possible for the decoder to go from transparent to white.

The only other place those pixels are modified is in unfilter, depalette, and convert. Scanning over these they are just reading from source directly, not modifying color. If a bug were here in these 3 there would probably be very drastic visual effects.

So looks like the empty atlas portions are defaulted to white, and individual images are not touched as far as I can tell. I can double check at home.

[RandyGaul]

For now go ahead and try adding in a define for default background color and see if that works. Feel free to re-open the issue if needed! :)

[RandyGaul]

Oh one more thing, I am doing premultiplied alpha here. Maybe this produced an unexpected result somehow? Perhaps this should be hidden behind a #define option...

[zacharycarter]

Okay so here are my findings @RandyGaul :

1. Commenting out the call to premultiply alpha does not fix the problem.
2. I believe maybe this - https://github.com/RandyGaul/tinyheaders/blob/master/tinydeflate.h#L1834 - assignment to the alpha component might be the issue?

I've attached a small self-contained example you should be able to compile with gcc / clang. In this example I'm trying to pack four images with transparent backgrounds, yet the resulting image has a white background. Even if I set the background color for the image from 0xFFFFFFFF to 0x00000000, the images themselves are still composited with a white background. I'm still not 100% sure why. Hopefully this example helps get to the root of the problem.

example.zip

I'm unable to reopen the issue, I could create a new one if desired.

[RandyGaul]

Interesting I'll take a look. That line should only be affecting png files saved with a palette... Hmm.

[zacharycarter]

No problem, glad I could help reproduce it! Thanks for the great set of libraries!

[RandyGaul]

Also added your nice bind file + test images to examples folder. Hope you don't mind! If it's a problem I can remove it or change the images :)