LodePNG crashes on re-encoded file

[CMPXCHG8B]

Greetings!

I'm experiencing some odd behaviour with LodePNG and I was wondering if you might be able to help me. I'll be honest- I have no idea if this is even a problem with LodePNG, or my compiler (Clang/LLVM 5.1) or both.

Anyways, I've got a really simple utility here that I use to do some math stuff on the pixel values directly. I'm using the C equivalent of the code found in example_reencode.cpp to load a PNG, perform some math functions on the pixel values, and then dump the entire thing back to disk.

Here's where things get weird- the program works fine with any input PNG created by a program other then LodePNG. It runs, processes the file, dumps it to disk, and quits successfully. If I run my program on that output file as the input file, LodePNG seems to load part of the image into memory- but then the the pixels start returning all zeros for their values around 40% of the way through, and eventually the entire thing crashes with EXEC_BAD_ACCESS.

I've tried compiling example_reencode.cpp and running that on a series of files (constantly feeding the output back into the input and running the program again) and that seems to work just fine. Likewise, I've discovered if I set state.decoder.color_convert to 1 (instead of 0), then my program runs fine without crashing (but I don't want any color conversion!).

I can post the source code somewhere if you'd like to take a look at it, though there's nothing terribly complicated about it. I'm just iterating through the pixels individually like so:

for (unsigned int y = 0; y < height; y ++)
{
    for (unsigned int x = 0; x < width; x ++)
    {
        unsigned int r = image[4 * width * y + 4 * x + 0];
        unsigned int g = image[4 * width * y + 4 * x + 1];
        unsigned int b = image[4 * width * y + 4 * x + 2];
        unsigned int a = image[4 * width * y + 4 * x + 3];

        /* Do math stuff here with r, g, b, and a */

        image[4 * width * y + 4 * x + 0] = r;
        image[4 * width * y + 4 * x + 1] = g;
        image[4 * width * y + 4 * x + 2] = b;
        image[4 * width * y + 4 * x + 3] = a;
    }
}

Is it something I'm doing, or is there a weird glitch in the C version of LodePNG? The fact that things don't go sideways if I set state.decoder.color_convert to 1 makes me think that it has something to do with the colour conversion code, but alas the majority of LodePNG is somewhat beyond my understanding :(.

Thanks in advance for any assistance you can provide! -CMPX

[lvandeve]

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?

[CMPXCHG8B]

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

[lvandeve]

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!

[CMPXCHG8B]

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.

[lvandeve]

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 :)