LodePNG入門
LodePNGは、PNG画像デコーダおよびエンコーダがセットされたコードファイルであり、zlibおよびlibpngのような外部リンク/ライブラリに依存せず、便利で友好的なPNGコーデック呼び出し方法を提供する.LodePNGは主にC(ISO C 90)を用いて作成され、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:SDLでPNG画像をC++で表示する方法. 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画像に変換する方法.
いくつかの一般的な関数:
この関数は1枚の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).
この関数は元の画素データを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-マシンビジュアルマイクロブログ:林建民-マシンビジュアル
LodePNGファイル:
lodepng.cpp:このLodePNGの本体部分には、PNGのコーデックのコア機能が実現されており、言うまでもなく.
lodepng.c:c言語で使用する場合は、上のファイルの名前をlodepngに変更します.cでいいです.
lodepng.h:lodepngです.cppとlodepng.cのヘッダファイル.
適用インスタンス:
いくつかの一般的な関数:
unsigned lodepng_decode_memory(unsigned char** out, unsigned* w, unsigned* h,
const unsigned char* in, size_t insize,
LodePNGColorType colortype, unsigned bitdepth);
この関数は1枚の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-マシンビジュアルマイクロブログ:林建民-マシンビジュアル