LodePNG crashes on re-encoded file about lodepng HOT 5 CLOSED

By default, LodePNG will always add an alpha channel to the raw output image. You always get 32-bit RGBA. Even on opaque images. This is on purpose: by default, you get the output in one consistent format for convenience. And that must have the alpha channel to be compatible with everything. So there is no phantom alpha channel, it is by definition that you get it.

You can also get it without alpha channel if you wish, see the API in the header file: there are functions to get it with 24-bit RGB, and functions where you can specify the color type and number of bits you want yourself. And then of course you can turn off color_convert, but then you can get ANY of PNG's many color formats, so that requires a lot of work from your side then to handle all different amounts of bits and channels.

Also, when saving a PNG, if the image is opaque (all alpha values 255), LodePNG will use RGB, not RGBA, inside of the PNG (it will also use greyscale if all pixels are grey, palette if there are <= 256 colors, etc...). This because PNG is image compression, so if there is no reason to store alpha values, it doesn't, which may be why when you save again, the alpha channel is gone again.

The main point is, that with this library, there is no link between the raw pixels color format and the color format inside the PNG. This is different than Photoshop, which keeps the uncompressed image in a color format similar to what was inside the PNG. But LodePNG gives you by default one consistent uncompressed format, and also by default encodes the PNG in the smallest possible color format for better compression, but that should be seen as independent from the uncompressed pixels' format.

I hope we're talking about the same thing here though :)

from lodepng.

Hi,

Is maybe the color format different?

The sample code from "example_reencode.cpp" turns off color_convert somewhere, if that is the case then you don't get the pixels in RGBA, but in whatever format they were in the PNG, which could be smaller and explain out of bounds errors.

Maybe it works better by basing the decoding on the simpler "example_decode.c(pp)" instead. Those examples leave the settings at the default RGBA color model.

Does that help?

from lodepng.

Yes, it does!

I see now what's happening (and boy, do I ever feel stupid). I thought color_convert had to do with colour space conversion, but now I see LodePNG does none of that (which is precisely why I was using it in the first place).

For some reason, certain PNG files are reading in with an additional alpha channel, and others aren't. This is a bit strange because Photoshop reports that none of the files have an alpha channel, but who knows what it's doing in the background. The files that read in with an alpha channel need to be addressed as having 4 channel (obviously). When those files are read in and then saved to disk through LodePNG, the phantom alpha channel gets stripped away, and when that same file is loaded back into LodePNG, only three channels are present (which explains why my code was bombing out precisely 75% of the way through the file). This isn't much of a problem since I don't actually use the alpha channel for anything, nor should it even be there in the file.

I'm not entirely sure who is at fault here (probably Adobe)- but I don't entirely care. With your assistance I've found the problem and fixed it, and my utility is working again. Thank you again for your help! I really do appreciate it.

-CMPX

from lodepng.

If color_convert is 1, which is its default value, then LodePNG should always color convert to the same format. So normally it shouldn't be that it sometimes does and sometimes doesn't add an alpha channel.

With everything at default, LodePNG should always output the image in 32-bit RGBA, no matter what is inside the PNG image. So it does color space conversion!

from lodepng.

Yeah, if color_convert is 1 then everything works 100% of the time. My original utility had color_convert set to 0 and made the foolish assumption that there'd always be 4 channels to work with (RGBA), which is what LodePNG said the format was so I just hardcoded that into the utility.

It wasn't until things started crashing that I realized there was no alpha channel, nor should there have been. Photoshop claims there is no alpha channel, and yet LodePNG will pick up a "phantom" channel with these files. Saving the file from LodePNG makes the phantom alpha disappear, which is why the utility was crashing on subsequent operations using files already pushed through LodePNG- the phantom alpha wouldn't get saved back to disk so the pixel addressing was off when that file was reloaded (at which point LodePNG would correctly report the image as RGB and not RGBA).

I can provide samples of all this if you wish to debug the issue further (I don't really have the technical knowledge and know absolutely zip about the PNG spec). Again, I have no idea if LodePNG is at fault or if Photoshop is doing something stupid or what. I'd be happy to help in any way I can if there's something wrong with LodePNG and you need my assistance in tracking it down.

from lodepng.