LodePNG入门

LodePNG是一个集合了PNG图像解码器和编码器的代码文件，不依赖于诸如zlib和libpng的外部链接/库，提供方便友好的PNG编解码器调用方法。LodePNG主要是采用C（ISO C90）编写的，并提供了C++的接口。LodePNG的使用非常简单，只要在项目文件中包含lodepng.cpp和lodepng.h或者lodepng.c和lodepng.h就可以。

LodePNG文件：

lodepng.cpp: 这个LodePNG的主体部分，里面实现了PNG的编解码的核心功能，无需多言。

lodepng.c: 如果你要在c语言下使用，只要把上面的文件重命名为lodepng.c就可以了。

lodepng.h: 是lodepng.cpp和lodepng.c的头文件。

应用例程：

• example_decode.cpp: 在C++下如何解码PNG文件。
• example_decode.c: 在C下如何解码PNG文件。
• example_encode.cpp: 在C++下如何将像素数据编码成PNG文件。
• example_encode.c: 在C下如何将像素数据编码成PNG文件。
• example_sdl.cpp: 在C++下如何利用SDL显示PNG图像。
• example_sdl.c: 在C下如何利用SDL显示PNG图像。
• example_opengl.cpp: 利用OpenGL显示PNG图像。
• example_png_info.cpp: 显示PNG的信息文件。
• example_4bit_palette.cpp: Generates 4-bit PNG with translucent palette
• example_reencode.cpp: Decodes PNG, then reencodes it close to the original
• example_optimize_png.cpp: Encodes a PNG with higher compression, but slower
• example_gzip.cpp: Encode a file to a gzip file (.gz)
• example_png2bmp.cpp: 如何将PNG图像转化为BMP图像。
• example_bmp2png.cpp: 如何将BMP图像转化为PNG图像。

几个常用函数：

unsigned lodepng_decode_memory(unsigned char** out, unsigned* w, unsigned* h,
                               const unsigned char* in, size_t insize,
                               LodePNGColorType colortype, unsigned bitdepth);

这个函数将一张PNG图像解码成原始的像素数据。

参数：

out:  Pointer to buffer that will contain the raw pixel data.After decoding, its size is w * h * (bytes per pixel) bytes larger than initially. Bytes per pixel depends on colortype and bitdepth.Must be freed after usage with free(*out).Note: for 16-bit per channel colors, uses big endian format like PNG does.

w:  Pointer to width of pixel data.

h: Pointer to height of pixel data.

in: Memory buffer with the PNG file.

insize: size of the in buffer.

colortype: the desired color type for the raw output image. See explanation on PNG color types.

bitdepth: the desired bit depth for the raw output image. See explanation on PNG color types.

Return value: LodePNG error code (0 means no error).

unsigned lodepng_encode_file(const char* filename,
                             const unsigned char* image, unsigned w, unsigned h,
                             LodePNGColorType colortype, unsigned bitdepth);

这个函数将原始的像素数据编码成一张PNG图像。

FAQ

Q: When using OpenGL and decoding textures with LodePNG, the image is upside down.
A: LodePNG uses a pixel order where it goes in rows from top to bottom. In OpenGL, how would you define upside down? There are many things which affect the orientation with which something is drawn in OpenGL: camera orientation, texture coordinates, the orientation of the object, ... If you don't want to solve the problem by changing OpenGL coordinates, e.g. because your game engine uses a bottom to top representation for all textures, you can still go through the raw pixel buffer of LodePNG with a for loop and swap the rows to become upside down. Remember that for 32-bit RGBA, each row is (width * 4 bytes) long, for 24-bit RGB it's (width * 3 bytes) long.

Q: The image is wrong when using LodePNG with BITMAPs in Visual Studio or win32, or with BMP images.
A: LodePNG uses raw buffers with RGBA or RGB pixels in the common order RGBARGBARGBA... or RGBRGBRGBRGB..., from top to bottom, without any special byte boundaries. BMP images and bitmaps in win32 use a different format. They do three things differently:
Instead of being from top to bottom, it goes from bottom to top (upside down).
Instead of using the order red, green, blue, it uses the order blue, green, red, or BGRBGRBGR..., (can result in wrong colors).
It has a limitation where rows always must be a multiple of 4 bytes, so if the width of the image is not a multiple of 4 some unused bytes are introduced at the end of each row (can result in a skewed image).
All of this are related to how BMP works, not how PNG or LodePNG work. When you're working with BMP, you need to take each of these three things into account and convert this to/from the buffer format that LodePNG uses. Also check out the png2bmp and bmp2png samples, which already do this.

Q: What's the difference between zlib, deflate and gzip? And between CRC32 and ADLER32?
A: That can be confusing. In short:
PNG uses zlib. Zlib uses deflate. Gzip uses deflate and is not used by PNG.
PNG uses CRC32, and indirectly ADLER32. Zlib uses ADLER32. Gzip uses CRC32.
IETF Standards: PNG is RFC 2083. Zlib is RFC 1950. Deflate is RFC 1951. Gzip is RFC 1952.

Q: Why did the interface of LodePNG change? Why not keep it as is, fixing compile errors is annoying!
A: Sorry about that. Sometimes when a feature is added the interface grows into something inconsistent, and then I try to redesign it to get a new, better, one. And sometimes when a new feature is added the cleanest way to do it requires an interface change. In the last change, the following improvements were made that changed it:
There used to be some fields in camelCase, and others with_underscores. Now, this is made more consistent: all fields and functions use underscore between words (except between two nouns that form one word, like bitdepth or palettesize), and all typenames start with a capital and use CamelCase.
The large amount of structs got reduced a bit.
The C++ class got removed: there was really no reason to have a class here. A encoder and decoder class with subclass implementations makes sense in a framework that can encode/decode many different image formats, but not in a single format like here. Instead, a convenient RAII wrapper lodepng::State is available around the new LodePNGState struct.
The C++ namespace is lodepng instead of LodePNG because namespaces look better in small letters imho.

官方原文链接：http://lodev.org/lodepng/

更多相关资源请关注 博客：LinJM-机器视觉   微博：林建民-机器视觉