PNG encoder and decoder in C and C++.

Overview

LodePNG

PNG encoder and decoder in C and C++, without dependencies

Home page: http://lodev.org/lodepng/

Documentation

Detailed documentation is included in a large comment in the second half of the header file lodepng.h.

Source code examples using LodePNG can be found in the examples directory.

An FAQ can be found on http://lodev.org/lodepng/

Building

Only two files are needed to encode and decode PNGs:

  • lodepng.cpp (or renamed to lodepng.c)
  • lodepng.h

All other files are just source code examples, tests, misc utilities, etc..., which are normally not needed in projects using this.

You can include the files directly in your project's source tree and its makefile, IDE project file, or other build system. No library is necessary.

In addition to C++, LodePNG also supports ANSI C (C89), with all the same functionality: C++ only adds extra convenience API.

For C, rename lodepng.cpp to lodepng.c.

Consider using git submodules to include LodePNG in your project.

Compiling in C++

If you have a hypothetical your_program.cpp that #includes and uses lodepng.h, you can build as follows:

g++ your_program.cpp lodepng.cpp -Wall -Wextra -pedantic -ansi -O3

or:

clang++ your_program.cpp lodepng.cpp -Wall -Wextra -pedantic -ansi -O3

This shows compiler flags it was designed for, but normally one would use the compiler or build system of their project instead of those commands, and other C++ compilers are supported.

Compiling in C

Rename lodepng.cpp to lodepng.c for this.

If you have a hypothetical your_program.c that #includes and uses lodepng.h, you can build as follows:

gcc your_program.c lodepng.c -ansi -pedantic -Wall -Wextra -O3

or

clang your_program.c lodepng.c -ansi -pedantic -Wall -Wextra -O3

This shows compiler flags it was designed for, but normally one would use the compiler or build system of their project instead of those commands, and other C compilers are supported.

Makefile

There is a Makefile, but this is not intended for using LodePNG itself since the way to use that one is to include its source files in your program. The Makefile only builds development and testing utilities. It can be used as follows:

make -j

Comments
  • The entropy strategy implemented with integer gives worse compression than float version

    The entropy strategy implemented with integer gives worse compression than float version

    One of the regressions after updating lodepng in zopfli is that it choses entrop strategy less often than before. 20-c6-shouldbe-c4-rgbdata For example this file, zopflipng --lossy_transparent now chooses zero strategy and optimize it to 5811 bytes while previously it chooses entropy and optimize it to 5642 bytes. Even if I force entropy strategy with --filters=e, 5719 bytes is still not as good as before.

    I nailed it down to this commit https://github.com/lvandeve/lodepng/commit/3d639635bb1b00ef21d11ce478373991c3eca1d5 and verified that after reverting it can now optimize to 5642 bytes like before.

    What's the rationale behind removing usage of float? Is it for speed? I did not notice any speed difference in my testing.

    opened by JayXon 8
  • Fixed Fuzzer, added Seed Corpus and Dictionary

    Fixed Fuzzer, added Seed Corpus and Dictionary

    Hi,

    There is a small bug in the lodepng_fuzzer.cpp code in lines 62 and 63, due to which whenever any input is passed for decoding, it is never tested positive as a png file and always gives error. Due to this, the lines between 85-91 are never executed and thus the functions in them are never tested.

    lodepng norun

    This can also be observed in the oss-fuzz reports which you can find here (dated: 06/11/2020):

    Coverage Report lodepng

    By removing those two lines and adding a dictionary and seeds of png images. The code coverage increased by more than 10%. For testing, I ran the modified fuzzer along with some seed pngs and a dictionary, locally for 10 Million runs (< 5 minutes on single core execution), then the following results were obtained:

    Local Testing Final

    The coverage has increased by ~8% in all categories.

    I have also added some seed png images and a dictionary for png files, all of which is open source and free to use. Links are available here which you can check:

    1. Seed PNGs Link 1: https://lcamtuf.coredump.cx/afl/demo/
    2. Seed PNGs Link 2: https://github.com/glennrp/libpng/tree/libpng16/contrib/pngsuite
    3. Dictionary: https://github.com/glennrp/libpng/blob/libpng16/contrib/oss-fuzz/png.dict

    If the above changes looks good, we can make the update the script in oss-fuzz repository to support dictionary and seed corpus.

    Summary of File Changes:

    1. Fixed a Bug in the Fuzzer due to which not even all inputs were considered non-png.
    2. Added Seed corpus for the fuzzer.
    3. Added Dictionary for the fuzzer.
    opened by iamarshsingh 7
  • SWF (flash) image transparency

    SWF (flash) image transparency

    Hello, this may not be an issue but more of a question. My problem is the following, I am trying to replace images in an SWF file, I load a PNG to memory and decode it, then convert RGBA to ARGB and everything appears to work great... except when I tried a PNG image with an embeded sRGB color profile. What happens is that Flash Player makes the transparent background white in this case. If I open the image in GIMP and export it, untick "Save background color", "Save resolution", "Save creation time", "Save color values from transparent pixels", "Save Exif data" and "Save color profile", basically getting rid of all the metadata and color profile, then it works as expected. Is there a way to do this with this library?

    opened by MangaD 7
  • Provide header only version

    Provide header only version

    It would be great, if a header only version does exist or could easily be created.

    When doing a lot of cross platform development, a header only version avoids maintaining and building the libraries for new versions.

    opened by McNopper 7
  • Fix warnings on const cast correctness

    Fix warnings on const cast correctness

    ../third_party/lodepng/lodepng.cpp:4055:45: warning: cast from 'const unsigned char *' to 'unsigned char *' drops const qualifier [-Wcast-qual]
                                (unsigned char*)(&data[string2_begin]),
                                                ^
    ../third_party/lodepng/lodepng.cpp:4135:47: warning: cast from 'const unsigned char *' to 'unsigned char *' drops const qualifier [-Wcast-qual]
                                  (unsigned char*)(&data[begin]),
                                                  ^
    ../third_party/lodepng/lodepng.cpp:4248:43: warning: cast from 'const unsigned char *' to 'unsigned char *' drops const qualifier [-Wcast-qual]
                              (unsigned char*)(&data[string2_begin]),
                                              ^
    ../third_party/lodepng/lodepng.cpp:4778:41: warning: cast from 'const char *' to 'unsigned char *' drops const qualifier [-Wcast-qual]
                            (unsigned char*)textstring, textsize, zlibsettings);
                                            ^
    ../third_party/lodepng/lodepng.cpp:4811:43: warning: cast from 'const char *' to 'unsigned char *' drops const qualifier [-Wcast-qual]
                              (unsigned char*)textstring, textsize, zlibsettings);
                                              ^
    5 warnings generated.
    
    opened by DennisOSRM 6
  • Replace

    Replace "//" to "/* text */"

    GCC warn me, that C90 is not supports "//" (C++ commentary style). Can you replace it in original files too? I do not want to use "Altered source" mark.

    opened by DeXP 6
  • Bug fix for previous erroneous pull request, plus further optimisation

    Bug fix for previous erroneous pull request, plus further optimisation

    I found and resolved the issue that caused my previous untested pull request to fail (10bb7ca). I realise you said that your choice of post-increment and less-than comparison is a matter of style, but I've now benchmarked this fork against the original, and I consistently get runtimes taking 97% the time of the original to carry out the unit test (timed in batches of 100), both at optimisation levels -O0 and -O3, meaning these changes represent an approximately 3% speedup even with optimisation.

    Not all of the changes will affect performance (mostly the loop comparisons will), so feel free to merge only part of this if you really feel strongly about keeping post-increments, although I personally think it's a matter of good style to prefer post-increment in all cases when working with C++ on principle.

    opened by slowriot 6
  • Allow a zero sized iCCP chunk.

    Allow a zero sized iCCP chunk.

    This fixes ~~two issues~~ one issue:

    1. malloc(0) is allowed to return NULL as a value, so we shouldn't always be counting a NULL return value from malloc() as an allocation error. ~~2) A memcpy() with a nullptr as the source or destination is undefined behaviour, even if the length to copy is zero.~~

    I don't see anything specifically disallowing a zero sized iCCP chunk in the PNG spec, however the behaviour of LodePNG would have been inconsistent depending on whether or not the allocator returned NULL for a zero sized allocation or not.

    opened by bobsayshilol 5
  • Fix ABI incompatibility when calling a C++ compiled lodepng.cpp from C code or vice versa

    Fix ABI incompatibility when calling a C++ compiled lodepng.cpp from C code or vice versa

    The addition of a virtual destructor to LodePNGState when compiled as C++ causes a vptr to be added at the start of the struct. This results in the members of the struct changing their offset depending on whether they're seen from C or C++ code. Internally the LodePNGState struct is never deleted (as to invoke the virtual destructor) and has no virtual methods called on it so it doesn't need to be virtual. Hence fix the ABI incompatibility by removing the virtual destructor.

    A demonstration of the problem using Compiler Explorer: https://godbolt.org/z/UJHBLf. Note that when compiled as C++ the offset of error moves 8B further into the struct due to the pointer inserted at the beginning.

    Dropping the virtual destructor for LodePNGState also allowed the dropping of the virtual keyword from lodepng::State::~State() as described in the commit message.

    opened by bobsayshilol 5
  • fix compiler warnings about const-breaking cast

    fix compiler warnings about const-breaking cast

    buffer is already declared as const unsigned char*, which can be transparently accepted by fwrite(). Casting it to char* here just makes compilers complain about "discarding cv-qualifiers", so this commit removes that cast.

    opened by Jesin 5
  • LodePNG crashes when loading a 24bit PNG from file

    LodePNG crashes when loading a 24bit PNG from file

    In function lodepng_inspect() in lodepng.c on line 3941: *w = lodepng_read32bitInt(&in[16]);

    Crashes when trying to load this PNG: https://www.icloud.com/iclouddrive/0FyWzALaAoBRYh7cW6thjLUog#tonninseteli.png

    I get EXC_BAD_ACCESS

    System specs OS: macOS 10.14 Mojave (Darwin 18.0.0) Compiler: Apple LLVM 10.0.0

    I tried merging in the latest version from this repo (20180326), and the problem persists.

    opened by vkoskiv 5
  • How to get a JSON string from the encoded image ?

    How to get a JSON string from the encoded image ?

    Hi,

    I want to send images encoded with this library plus some metadata as strings to another C program. I have some problems:

    1. The bytes of the encoded image contains many string null terminator characters ('\0') in the middle. So, the C string libs can't create the string from the bytes array. As a work around, I created my own encoder for this special case, which uses memcpy C lib function to copy the PNG bytes to my string. But this isn't a valid C string. There are many '\0' in the middle.

    2. The receiver of the data also can't decode the "string" using C JSON libs because of the same reason (null terminator characters ('\0') in the middle). As a work around, I created my own decoder for this special case, which will look for characters like ',' to identify the end of the PNG bytes and the start of the other message fields.

    Is there some better idea ? Maybe there is some lib that implements JSON encoding for the PNG bytes ? I can't find any mention to this in the source code of this lib.

    Thanks in advance

    opened by joaopfg 3
  • Memory leaks in function benchmark.

    Memory leaks in function benchmark.

    Detail

    ================================================================= ==1082665==ERROR: LeakSanitizer: detected memory leaks

    Direct leak of 16384 byte(s) in 4 object(s) allocated from: #0 0x495dcd in malloc (/home/hjsz/fuzz_software/lodepng-master/benchmark+0x495dcd) #1 0x4fee62 in lodepng_malloc(unsigned long) /home/hjsz/fuzz_software/lodepng-master/lodepng.cpp:78:10 #2 0x4fee62 in lodepng_decode(unsigned char**, unsigned int*, unsigned int*, LodePNGState*, unsigned char const*, unsigned long) /home/hjsz/fuzz_software/lodepng-master/lodepng.cpp:5055:28 #3 0x52ecfc in testDecode(std::vector<unsigned char, std::allocator > const&) /home/hjsz/fuzz_software/lodepng-master/lodepng_benchmark.cpp:197:26 #4 0x5318a5 in testFile(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) /home/hjsz/fuzz_software/lodepng-master/lodepng_benchmark.cpp:261:5 #5 0x533b28 in main /home/hjsz/fuzz_software/lodepng-master/lodepng_benchmark.cpp:312:5 #6 0x7f6fd43cf082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16

    SUMMARY: AddressSanitizer: 16384 byte(s) leaked in 4 allocation(s). Thanks for your time.

    I saw the issues #165 , It should be the same problem. If the crash occues when normal user use the function rather than fuzzing the function?

    opened by yangfar 0
  • Че за хрень 64 бит компиляция

    Че за хрень 64 бит компиляция

    1>.\..\src\util\lodepng.cpp(687,54): warning C4334: <<: результат 32-разрядного смещения неявно преобразуется в 64-разрядное значение (предполагалось 64-разрядное смещение?)
    1>.\..\src\util\lodepng.cpp(705,35): warning C4267: =: преобразование из "size_t" в "unsigned short"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(706,39): warning C4334: <<: результат 32-разрядного смещения неявно преобразуется в 64-разрядное значение (предполагалось 64-разрядное смещение?)
    1>.\..\src\util\lodepng.cpp(730,37): warning C4267: =: преобразование из "size_t" в "unsigned short"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(747,38): warning C4267: =: преобразование из "size_t" в "unsigned short"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(3726,78): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(4729,33): warning C4267: =: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(4998,60): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5003,83): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5004,94): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5005,83): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5006,94): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5007,83): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5008,94): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5009,78): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5204,3): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5228,7): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5262,62): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5279,3): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5301,57): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5332,57): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5445,57): warning C4267: аргумент: преобразование из "size_t" в "unsigned int"; возможна потеря данных
    1>.\..\src\util\lodepng.cpp(5559,33): warning C4334: <<: результат 32-разрядного смещения неявно преобразуется в 64-разрядное значение (предполагалось 64-разрядное смещение?)
    
    opened by UnrealKaraulov 1
  • Minor LodePNG optimizations

    Minor LodePNG optimizations

    LodePNG code size is decreased by about 1.5kB when compiled with MSYS2 CLANG64 Clang 15.0.0

    Decoding (RGB and non-alpha grey colortypes) and encoding (any colortype) should be about 1-2% faster

    A warning is fixed in lodepng_benchmark.cpp so it can successfully be compiled with the recommended build command

    opened by woot000 0
  • Add vcpkg installation instructions

    Add vcpkg installation instructions

    lodepng is available as a port in vcpkg, a C++ library manager that simplifies installation for lodepng and other project dependencies. Documenting the install process here will help users get started by providing a single set of commands to build lodepng, ready to be included in their projects.

    We also test whether our library ports build in various configurations (dynamic, static) on various platforms (OSX, Linux, Windows: x86, x64) to keep a wide coverage for users.

    I'm a maintainer for vcpkg, and here is what the port script looks like. We try to keep the library maintained as close as possible to the original library. :)

    opened by JonLiu1993 0
  • Set hard limit for image buffer size

    Set hard limit for image buffer size

    A security researcher found that it was possible to make lodepng allocate a terabyte or more of memory by supplying bogus image dimensions. This adds a compiled-in upper limit on the size of the allocation for uncompressed image data.

    Maybe you want this to be configurable at runtime (possibly by generalizing zlibsettings->max_output_size). Any solution works for me as long as it's possible to specify a limit :-)

    opened by hpjansson 0
Owner
Lode Vandevenne
Lode Vandevenne
Arduino PNG image decoder library

An 'embedded-friendly' (aka Arduino) PNG image decoding library

Larry Bank 102 Jan 6, 2023
Simple, generally spec-compliant, hacky PNG Decoder written in C99.

Simple, generally spec-compliant, hacky PNG Decoder written in C99.

cristei 2 Nov 2, 2021
libspng is a C library for reading and writing PNG format files with a focus on security and ease of use.

libspng (simple png) is a C library for reading and writing Portable Network Graphics (PNG) format files with a focus on security and ease of use.

Randy 570 Dec 29, 2022
An image and texture viewer for tga, png, apng, exr, dds, gif, hdr, jpg, tif, ico, webp, and bmp files

An image and texture viewer for tga, png, apng, exr, dds, gif, hdr, jpg, tif, ico, webp, and bmp files. Uses Dear ImGui, OpenGL, and Tacent. Useful for game devs as it displays information like the presence of an alpha channel and querying specific pixels for their colour.

Tristan Grimmer 159 Dec 31, 2022
pngtostl is a program that converts a PNG image into STL 3D models

pngtostl is a program that converts a PNG image into a litophane, in STL format, suitable to be printed by entry level 3D printers.

Salvatore Sanfilippo 157 Dec 17, 2022
Very fast C++ .PNG writer for 24/32bpp images.

fpng Very fast C++ .PNG writer for 24/32bpp images. fpng.cpp was written to see just how fast you can write .PNG's without sacrificing too much compre

Rich Geldreich 639 Dec 25, 2022
Rate-Distortion Optimized Lossy PNG Encoding Tool

rdopng is a command line tool which uses LZ match optimization, Lagrangian multiplier rate distortion optimization (RDO), a simple perceptual error tolerance model, and Oklab-based colorspace error metrics to encode 24/32bpp PNG files which are 30-80% smaller relative to lodepng/libpng.

Rich Geldreich 40 Dec 24, 2022
Fast streaming PNG<->QOI converter with some compression-improving extensions

QOIG Fast streaming PNG<->QOI converter with some compression-improving extensions. Can achieve 1%-10% better compression than QOI without sacrificing

David Rutter 3 Oct 3, 2022
CGIF, A fast and lightweight GIF encoder that can create GIF animations and images

CGIF, a GIF encoder written in C A fast and lightweight GIF encoder that can create GIF animations and images. Summary of the main features: user-defi

Daniel Löbl 75 Dec 28, 2022
Guetzli is a JPEG encoder that aims for excellent compression density at high visual quality

Guetzli is a JPEG encoder that aims for excellent compression density at high visual quality. Guetzli-generated images are typically 20-30% smaller than images of equivalent quality generated by libjpeg. Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer.

Google 12.8k Jan 7, 2023
A deblocking JPEG decoder

Knusperli The goal of Knusperli is to reduce blocking artifacts in decoded JPEG images, by interpreting quantized DCT coefficients in the image data a

Google 454 Dec 22, 2022
Video, Image and GIF upscale/enlarge(Super-Resolution) and Video frame interpolation. Achieved with Waifu2x, SRMD, RealSR, Anime4K, RIFE, CAIN, DAIN and ACNet.

Video, Image and GIF upscale/enlarge(Super-Resolution) and Video frame interpolation. Achieved with Waifu2x, SRMD, RealSR, Anime4K, RIFE, CAIN, DAIN and ACNet.

Aaron Feng 8.7k Jan 7, 2023
C++ image processing and machine learning library with using of SIMD: SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AVX-512, VMX(Altivec) and VSX(Power7), NEON for ARM.

Introduction The Simd Library is a free open source image processing and machine learning library, designed for C and C++ programmers. It provides man

Ihar Yermalayeu 1.7k Jan 5, 2023
A crude untested example showing how to retrieve and display images from multiple cameras with OpenCV and wxWidgets.

About wxOpenCVCameras is a crude untested example of how to retrieve and display images from multiple cameras, using OpenCV to grab images from a came

PB 8 Dec 14, 2022
Generate Height map with Generator (OpenGL and imgui) and Construct Splat Map with generated height map using Algorithm

Generate Height map with Generator (OpenGL and imgui) and Construct Splat Map with generated height map using Algorithm(DPS, BFS, Gradient Descent ... etc) . At Renderer, with height map and blend map which are generated in front of this stage, render high quality terrain with OpenGL

Snowapril 35 Mar 22, 2022
A bunch of functions and helpers classes for D3D12, and DXGI libraries

TypedD3D A bunch of functions and helpers classes for D3D12, and DXGI libraries Namespaces Helpers A bunch of helper functions that interface more wit

Renzy Alarcon 8 Sep 15, 2022
A toolkit for making real world machine learning and data analysis applications in C++

dlib C++ library Dlib is a modern C++ toolkit containing machine learning algorithms and tools for creating complex software in C++ to solve real worl

Davis E. King 11.6k Dec 31, 2022