LodePNG

LodePNG for C (ISO C90) and C++

LodePNG is a PNG image decoder and encoder, all in one, no dependency or linkage to zlib or libpng required.
It's made for C (ISO C90), and has a C++ wrapper with a more convenient interface on top.

See lodepng.h for documentation.

  • lodepng.cpp: The source file for the C++ version (and after renaming it, for the C version)
  • lodepng.c: Just get lodepng.cpp and rename it to lodepng.c
  • lodepng.h: header for both the C and C++ version.
Usage examples: Other utilities:

picoPNG

There is also picoPNG, which is only the decoder part of LodePNG, wrapped in one single C++ function of around 500 lines. This is less well maintained than LodePNG, has less features, and may be less efficient.

The function, decodePNG, converts any PNG file data, with any colortype or interlace mode, into a 32-bit image in an std::vector at the output.

picopng.cpp

Other versions

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:

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:

Q: picoPNG doesn't support some feature.

A: Try LodePNG instead. It supports more than picoPNG, and is better maintained. The code of picoPNG may be small, but its compiled executable may not be. If you want to compile to a really small executable, then LodePNG can probably do this better because it supports the C language instead of only C++, and has the ability to turn off pieces of code you don't need by changing some #defines in the header.

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:

Change History

More detailed change history is in the header file.

  • 2005: LodePNG created for C++, it could only decode PNGs.
  • 2006: Many interface changes, fixes and improvements.
  • 2007: Full PNG and Zlib encoder and compressor added.
  • 2008: Converted all the code to C instead of C++, with a C++ wrapper around it.
  • 2010: Small bugfixes and header and documentation restructured.
  • 2012: Revamped interface with more consistent names, rewrote some parts, bugfixes.


Some other projects
Copyright (c) 2005-2013 by Lode Vandevenne. All rights reserved.