search

lvandeve / lodepng

PNG encoder and decoder in C and C++.
zlib License
2.09k stars 426 forks source link

Decode to existing buffer #17

Open OldFisher opened 9 years ago

OldFisher commented 9 years ago

Hi again. I noticed that LodePNG always allocates its own memory to hold decoded results. I'd like to have the possibility to provide my own buffer to receive decoded data. Currently I made a little makeshift patch so that providing non-null "out" will prevent allocation, but it's hardly a proper solution.

lvandeve commented 9 years ago

Hi,

This, along with better custom malloc support, is a big internal and API change, but planned at some point. Tho not soon for now.

To understand why the API is as-is: it was designed mainly for easy, one-function-call usage to load textures in games, in environments where memory usage is of no concern.

hostilefork commented 7 years ago

@lvandeve Hm, does this really require an interface change? Couldn't the existing function just call two support functions--one that gets the width and height, and another that does the decoding into a buffer big enough for that width and height? Then clients who want to do their own allocation just call those two support functions directly?

I note that getting the width and height is already supported as lodpng_inspect(), so really this just means one needs to name the version that decodes into an existing buffer. Nothing in the interface has to change.

kanryu commented 7 years ago

@lvandeve I agree to @hostilefork .

This problem can be solved simply by customizing the part of decodeGeneric() which forcibly substitutes the buffer of lodepng_malloc () for out.

You may provide additional arguments to change the mode of operation, or create a new function to write to the existing buffer (that is not difficult at all).

Simply, I think that it should be treated as an external buffer and skip allocation, if out has a value.

However, what I have to advise is that the current export buffer has a clearly incorrect padding method. It seems that lodepng_get_raw_size () is used in calculating the buffer size.

This is the correct calculation method:

return ((w * bpp / 8 + 3) / 4 * 4) * h ;

Each row of pixels must fulfill a 4-byte alignment.

Likewise, you should also manage bytesPerLine so that other buffer formats are acceptable.

RandomErrorMessage commented 1 year ago

Much needed feature request from 2015.