Lines Matching full:the
7 warranty. In no event will the authors be held liable for any damages
8 arising from the use of this software.
12 freely, subject to the following restrictions:
14 1. The origin of this software must not be misrepresented; you must not
15 claim that you wrote the original software. If you use this software
16 in a product, an acknowledgment in the product documentation would be
20 misrepresented as being the original software.
39 The following #defines are used to create code sections. They can be disabled
41 The "NO_COMPILE" defines are designed to be used to pass as defines to the
46 the custom_zlib field of the compress and decompress settings*/
48 …/*pass -DLODEPNG_NO_COMPILE_ZLIB to the compiler to disable this, or comment out LODEPNG_COMPILE_Z…
54 …/*pass -DLODEPNG_NO_COMPILE_PNG to the compiler to disable this, or comment out LODEPNG_COMPILE_PN…
60 …/*pass -DLODEPNG_NO_COMPILE_DECODER to the compiler to disable this, or comment out LODEPNG_COMPIL…
66 …/*pass -DLODEPNG_NO_COMPILE_ENCODER to the compiler to disable this, or comment out LODEPNG_COMPIL…
70 /*the optional built in harddisk file loading and saving functions*/
72 …/*pass -DLODEPNG_NO_COMPILE_DISK to the compiler to disable this, or comment out LODEPNG_COMPILE_D…
78 /*pass -DLODEPNG_NO_COMPILE_ANCILLARY_CHUNKS to the compiler to disable this,
85 /*pass -DLODEPNG_NO_COMPILE_ERROR_TEXT to the compiler to disable this,
90 /*Compile the default allocators (C's free, malloc and realloc). If you disable this,
91 you can define the functions lodepng_free, lodepng_malloc and lodepng_realloc in your
94 /*pass -DLODEPNG_NO_COMPILE_ALLOCATORS to the compiler to disable the built-in ones,
101 The default built-in CRC code comes with 8KB of lookup tables, so for memory constrained environmen…
103 in a comment in the lodepng.c(pp) file in the 'else' case of the searchable LODEPNG_COMPILE_CRC sec…
105 /*pass -DLODEPNG_NO_COMPILE_CRC to the compiler to disable the built-in one,
110 /*compile the C++ version (you can disable the C++ wrapper here even when compiling for C++)*/
113 … /*pass -DLODEPNG_NO_COMPILE_CPP to the compiler to disable C++ (not needed if a C-only compiler),
125 /*The PNG color types (also used for raw image).*/
132 /*LCT_MAX_OCTET_VALUE lets the compiler allow this enum to represent any invalid
134 not use, compare with or set the name LCT_MAX_OCTET_VALUE, instead either use
135 the valid color type names above, or numeric values like 1 or 7 when checking for
143 out: Output parameter. Pointer to buffer that will contain the raw pixel data.
150 in: Memory buffer with the PNG file.
151 insize: size of the in buffer.
152 colortype: the desired color type for the raw output image. See explanation on PNG color types.
153 bitdepth: the desired bit depth for the raw output image. See explanation on PNG color types.
171 Same as the other decode functions, but instead takes a filename as input.
198 Converts raw pixel data into a PNG image in memory. The colortype and bitdepth
199 of the output PNG image cannot be chosen, they are automatically determined
200 by the colortype, bitdepth and content of the input pixel data.
202 out: Output parameter. Pointer to buffer that will contain the PNG image data.
204 outsize: Output parameter. Pointer to the size in bytes of the out buffer.
205 image: The raw pixel data to encode. The size of this buffer should be
207 w: width of the raw pixel data in pixels.
208 h: height of the raw pixel data in pixels.
209 colortype: the color type of the raw input image. See explanation on PNG color types.
210 bitdepth: the bit depth of the raw input image. See explanation on PNG color types.
228 Same as the other encode functions, but instead takes a filename as output.
259 /*Same as lodepng_decode_memory, but decodes to an std::vector. The colortype
260 is the format to output the pixels to. Default is RGBA 8-bit per channel.*/
270 Same as the other decode functions, but instead takes a filename as input.
283 is that of the raw input data. The output PNG color type will be auto chosen.*/
293 Same as the other encode functions, but instead takes a filename as output.
313 /*Returns an English description of the numerical error code.*/
322 …unsigned ignore_adler32; /*if 1, continue and don't give an error message if the Adler32 checksum …
325 /*Maximum decompressed size, beyond this the decoder may (and is encouraged to) stop decoding,
326 return an error, output a data size > max_output_size and all the data up to that point. This is
328 …ignored by the PNG decoder, but is used by the deflate/zlib decoder and can be used by custom ones.
329 Set to 0 to impose no limit (the default).*/
338 if custom_zlib is not null, custom_inflate is ignored (the zlib format uses deflate).
353 Settings for zlib compression. Tweaking these settings tweaks the balance
359 …unsigned btype; /*the block type for LZ (0, 1, 2 or 3, see zlib standard). Should be 2 for proper …
371 if custom_zlib is used, custom_deflate is ignored since only the built in
386 Color mode of an image. Contains all information required to decode the pixel
387 bits to RGBA colors. This information is the same as used in the PNG file
398 Dynamically allocated with the colors of the palette, including alpha.
403 The alpha channels must be set as well, set them to 255 for opaque images.
405 When decoding, with the default settings you can ignore this palette, since
406 LodePNG already fills the palette colors in the pixels of the raw RGBA output,
407 but when decoding to the original PNG color mode it is needed to reconstruct
408 the colors.
410 The palette is only supported for color type 3.
418 …This color uses the same bit depth as the bitdepth value in this struct, which can be 1-bit to 16-…
419 For grayscale PNGs, r, g and b will all 3 be set to the same.
422 pixels with this key to transparent already in the raw RGBA output.
424 The color key is only supported for color types 0 and 2.
441 /*add 1 color to the palette*/
445 /*get the total amount of bits per pixel, based on colortype and bitdepth in the struct*/
447 /*get the amount of color channels used, based on colortype in the struct.
456 /*only returns true if there is a palette and there is a value in the palette with alpha < 255.
457 Loops through the palette to check this.*/
460 Check if the given color info indicates the possibility of having non-opaque pixels in the PNG imag…
461 Returns true if the image can have translucent or invisible pixels (it still be opaque if it doesn'…
462 Returns false if the image can only have opaque pixels.
467 /*Returns the byte size of a raw image buffer with given width, height and color mode*/
471 /*The information of a Time chunk in PNG.*/
482 /*Information about the PNG image, except pixels, width and height.*/
485 unsigned compression_method;/*compression method of the original file. Always 0.*/
486 unsigned filter_method; /*filter method of the original file*/
487 unsigned interlace_method; /*interlace method of the original file: 0=none, 1=Adam7*/
488 LodePNGColorMode color; /*color type and bits, palette and transparency of the PNG file*/
494 This uses the same color mode and bit depth as the PNG (except no alpha channel),
495 with values truncated to the bit depth in the unsigned integer.
497 For grayscale and palette PNGs, the value is stored in background_r. The values
498 in background_g and background_b are then unused. The decoder will set them
499 equal to background_r, the encoder ignores them in this case.
501 When decoding, you may get these in a different color mode than the one you requested
502 for the raw pixels: the colortype and bitdepth defined by info_png.color, that is the
503 ones defined in the header of the PNG image, are used.
505 When encoding with auto_convert, you must use the color model defined in info_png.color for
506 these values. The encoder normally ignores info_png.color when auto_convert is on, but will
510 when the image is gray, or the compression will be worse since it will be forced to
511 write the PNG with a more expensive color mode (when auto_convert is on).
513 The decoder does not use this background color to edit the color of pixels. This is a
524 The char** arrays each contain num strings. The actual messages are in
526 the actual text represents, e.g. Title, Author, Description, or anything else.
528 … All the string fields below including strings, keys, names and language tags are null terminated.
529 The PNG specification uses null characters for the keys, names and tags, and forbids null
530 characters to appear in the main text which is why we can use null termination everywhere here.
532 A keyword is minimum 1 character and maximum 79 characters long (plus the
536 Don't allocate these text buffers yourself. Use the init/cleanup functions
541 …size_t text_num; /*the amount of texts in these char** buffers (there may be more texts in itext)*/
542 char ** text_keys; /*the keyword of a text chunk (e.g. "Comment")*/
543 char ** text_strings; /*the actual text*/
547 Similar to the non-international text chunks, but with additional strings
548 "langtags" and "transkeys", and the following text encodings are used:
550 keys must be 1-79 characters (plus the additional null terminator), the other
553 size_t itext_num; /*the amount of international texts in this PNG*/
554 char ** itext_keys; /*the English keyword of the text chunk (e.g. "Comment")*/
556 char ** itext_transkeys; /*keyword translated to the international language - UTF-8 string*/
557 char ** itext_strings; /*the actual international text - UTF-8 string*/
560 unsigned time_defined; /*set to 1 to make the encoder generate a tIME chunk*/
564 …unsigned phys_defined; /*if 0, there is no pHYs chunk and the values below are undefined, if 1 els…
572 …LodePNG does not apply any color conversions on pixels in the encoder or decoder and does not inte…
573 …profile values. It merely passes on the information. If you wish to use color profiles and convert…
576 See the PNG, ICC and sRGB specifications for more information about the meaning of these values.
595 sRGB chunk: optional. May not appear at the same time as iCCP.
603 iCCP chunk: optional. May not appear at the same time as sRGB.
605 …LodePNG does not parse or use the ICC profile (except its color space header field for an edge cas…
606 …separate library to handle the ICC data (not included in LodePNG) format is needed to use it for c…
609 …f iCCP is present, gAMA and cHRM are recommended to be added as well with values that match the ICC
610 …profile as closely as possible, if you wish to do this you should provide the correct values for g…
611 …enable their '_defined' flags since LodePNG will not automatically compute them from the ICC profi…
613 …For encoding, the ICC profile is required by the PNG specification to be an "RGB" profile for non-…
615 …the ICC profile type matches your requested color type, else the encoder gives an error. If auto_c…
616 …enabled (the default), and the ICC profile is not a good match for the pixel data, this will resul…
617 …error if the pixel data has non-gray pixels for a GRAY profile, or a silent less-optimal compressi…
618 data if the pixels could be encoded as grayscale but the ICC profile is RGB.
620 …To avoid this do not set an ICC profile in the image unless there is a good reason for it, and whe…
621 make sure you compute it carefully to avoid the above problems.
626 The ICC profile in iccp_profile_size bytes.
627 Don't allocate this buffer yourself. Use the init/cleanup functions
631 unsigned iccp_profile_size; /* The size of iccp_profile in bytes */
636 …If defined, these values give the bit depth of the original data. Since PNG only stores 1, 2, 4, 8…
637 …per channel data, the significant bits value can be used to indicate the original encoded data has…
640 Encoders using this value, when storing the pixel data, should use the most significant bits
641 of the data to store the original bits, and use a good sample depth scaling method such as
642 "left bit replication" to fill in the least significant bits, rather than fill zeroes.
645 shift the data to go back to the original bit depth, but decoders are also allowed to ignore
646 sbit and work e.g. with the 8-bit or 16-bit data from the PNG directly, since thanks
647 to the encoder contract, the values encoded in PNG are in valid range for the PNG bit depth.
651 translucent palette values, or images with color key). The values that are used must be
652 greater than zero and smaller than or equal to the PNG bit depth.
654 The color type from the header in the PNG image defines these used and unused fields: if
656 only uses the color type of the original PNG, and may e.g. lack the alpha channel info
657 if the PNG was RGB. When encoding with auto_convert (as well as without), also always the
660 NOTE: enabling sbit can hurt compression, because the encoder can then not always use
661 auto_convert to choose a more optimal color mode for the data, because the PNG format has
662 strict requirements for the allowed sbit values in combination with color modes.
663 …For example, setting these fields to 10-bit will force the encoder to keep using a 16-bit per chan…
664 color mode, even if the pixel data would in fact fit in a more efficient 8-bit mode.
666 unsigned sbit_defined; /*is significant bits given? if not, the values below are unused*/
678 There are 3 buffers, one for each position in the PNG where unknown chunks can appear.
680 The 3 positions are:
684 …above in here, since the encoder will blindly follow this and could then encode an invalid PNG file
685 (such as one with two IHDR chunks or the disallowed combination of sRGB with iCCP). But do use
689 Do not allocate or traverse this data yourself. Use the chunk traversing functions declared
693 size_t unknown_chunks_size[3]; /*size in bytes of the unknown chunks, given for protection*/
705 void lodepng_clear_text(LodePNGInfo * info); /*use this to clear the texts again after you filled t…
708 … const char * transkey, const char * str); /*push back the 4 texts of 1 chunk at once*/
709 void lodepng_clear_itext(LodePNGInfo * info); /*use this to clear the itexts again after you filled…
713 void lodepng_clear_icc(LodePNGInfo * info); /*use this to clear the texts again after you filled th…
718 LodePNGColorMode structs to describe the input and output color type.
719 See the reference manual at the end of this header file to see which color conversions are supporte…
720 return value = LodePNG error code (0 if all went ok, an error if the conversion isn't supported)
721 The out buffer must have size (w * h * bpp + 7) / 8, where bpp is the bits per pixel
722 of the output color type (lodepng_get_bpp).
723 For < 8 bpp images, there should not be padding bits at the end of scanlines.
733 Settings for the decoder. This contains settings for the PNG and the Zlib
734 decoder, but not the Info settings from the Info structs.
737 LodePNGDecompressSettings zlibsettings; /*in here is the setting to ignore Adler32 checksums*/
748 unsigned color_convert; /*whether to convert the PNG to the color type you want. Default: yes*/
751 …text_chunks; /*if false but remember_unknown_chunks is true, they're stored in the unknown chunks*/
753 …/*store all bytes from unknown chunks in the LodePNGInfo (off by default, useful for a png editor)…
761 …/* maximum size for compressed ICC chunks. If the ICC profile is larger than this, an error will b…
781 /*Use filter that gives minimum sum, as described in the official PNG filter heuristic.*/
783 /*Use the filter type that gives smallest Shannon entropy for this scanline. Depending
784 on the image, this is better or worse than minsum.*/
791 /*use predefined_filters buffer: you specify the filter type for each scanline*/
795 /*Gives characteristics about the integer RGBA colors of the image (count, alpha channel usage, bit…
801 …unsigned short key_r; /*key values, always as 16-bit, in 8-bit case the byte is duplicated, e.g. 6…
807 …palette[1024]; /*Remembers up to the first 256 RGBA colors, in no particular order, only valid whe…
811 /*user settings for computing/using the stats*/
813 …unsigned allow_greyscale; /*default 1. if 0, choose RGB or RGBA even if the image only has gray co…
818 /*Get a LodePNGColorStats of the image. The stats must already have been inited.
824 /*Settings for the encoder.*/
826 … LodePNGCompressSettings zlibsettings; /*settings for the zlib encoder, such as window size, ...*/
830 /*If true, follows the official PNG heuristic: if the PNG uses a palette or lower than
831 8 bit depth, set all filters to zero. Otherwise use the filter_strategy. Note that to
832 completely follow the official PNG heuristic, filter_palette_zero must be true and
839 the same length as the amount of scanlines in the image, and each value must <= 5. You
847 a palette must be present in the info_png.
864 /*The settings, state and information for extended encoding and decoding.*/
867 LodePNGDecoderSettings decoder; /*the decoding settings*/
870 LodePNGEncoderSettings encoder; /*the encoding settings*/
872 …LodePNGColorMode info_raw; /*specifies the format in which you would like to get the raw pixel buf…
873 LodePNGInfo info_png; /*info of the PNG image obtained after decoding*/
886 getting much more information about the PNG image and color mode.
893 Read the PNG header, but not the actual data. This returns only the information
894 that is in the IHDR chunk of the PNG, such as width, height and color type. The
895 information is placed in the info_png field of the LodePNGState.
904 of the PNG file and outputs what it read in the state. Returns error code on failure.
906 to find the desired chunk type, and if non null use lodepng_inspect_chunk (with
908 Supports most metadata chunks from the PNG standard (gAMA, bKGD, tEXt, ...).
918 /*This function allocates the out buffer with standard malloc and stores the size in *outsize.*/
925 The lodepng_chunk functions are normally not needed, except to traverse the
926 unknown chunks stored in the LodePNGInfo struct, or add new ones to it.
927 It also allows traversing the chunks of an encoded PNG file yourself.
929 The chunk pointer always points to the beginning of the chunk itself, that is
930 the first byte of the 4 length bytes.
932 In the PNG file format, chunks have the following format:
933 -4 bytes length: length of the data of the chunk in bytes (chunk itself is 12 bytes longer)
938 The first chunk starts at the 8th byte of the PNG file, the entire rest of the file
939 exists out of concatenated chunks with the above format.
949 Gets the length of the data of the chunk. Total chunk length has 12 bytes more.
950 There must be at least 4 bytes to read from. If the result value is too large,
955 /*puts the 4-byte type in null terminated string*/
958 /*check if the type is the given type*/
961 /*0: it's one of the critical chunk types, 1: it's an ancillary chunk (see PNG standard)*/
967 /*0: the chunk is unsafe to copy, 1: the chunk is safe to copy (see PNG standard)*/
970 /*get pointer to the data of the chunk, where the input points to the header of the chunk*/
974 /*returns 0 if the crc is correct, 1 if it's incorrect (0 for OK as usual!)*/
977 /*generates the correct CRC from the data and puts it in the last 4 bytes of the chunk*/
981 Iterate to next chunks, allows iterating through all chunks of the PNG file.
982 Input must be at the beginning of a chunk (result of a previous lodepng_chunk_next call,
983 or the 8th byte of a PNG file which always has the first chunk), or alternatively may
984 point to the first byte of the PNG file (which is not a chunk but the magic header, the
985 function will then skip over it and return the first real chunk).
986 Will output pointer to the start of the next chunk, or at or beyond end of the file if there
987 is no more chunk after this or possibly if the chunk is corrupt.
988 Start this process at the 8th byte of the PNG file.
989 In a non-corrupt PNG file, the last chunk should have name "IEND".
994 /*Finds the first chunk with the given type in the range [chunk, end), or returns NULL if not found…
1000 Appends chunk to the data in out. The given chunk should already have its chunk header.
1001 The out variable and outsize are updated to reflect the new reallocated buffer.
1007 Appends new chunk to out. The chunk to append is given by giving its length, type
1008 and data separately. The type is a 4-letter string.
1009 The out variable and outsize are updated to reflect the new reallocated buffer.
1024 buffer. It cannot be used to create gzip files however, and it only supports the
1029 /*Inflate a buffer. Inflate is the decompression step of deflate. Out buffer must be freed after us…
1035 Decompresses Zlib data. Reallocates the out buffer and appends the data. The
1036 data must be according to the zlib specification.
1047 Compresses data with Zlib. Reallocates the out buffer and appends the data.
1048 Zlib adds a small header and trailer around the deflate data.
1049 The data is output in the format of the zlib specification.
1058 Find length-limited Huffman code for given frequencies. This function is in the
1074 Load a file from disk into buffer. The function allocates the out buffer, and
1077 outsize: output parameter, size of the allocated out buffer
1078 filename: the path to the file to load
1088 the file without warning!
1089 buffer: the buffer to write
1090 buffersize: size of the buffer to write
1091 filename: the path to the file to save to
1101 /* The LodePNG C++ wrapper uses std::vectors instead of manually allocated memory buffers. */
1145 Save the binary data in an std::vector to a file on disk. The file is overwritten
1188 [X] let the "isFullyOpaque" function check color keys and transparent palettes too
1189 [X] better name for the variables "codes", "codesD", "codelengthcodes", "clcl" and "lldl"
1195 [ ] let the C++ wrapper catch exceptions coming from the standard library and return LodePNG error …
1245 LodePNG is a PNG codec according to the Portable Network Graphics (PNG)
1248 The specifications used are:
1257 The most recent version of LodePNG can currently be found at
1264 -lodepng.h: the header file for both C and C++
1265 -lodepng.c(pp): give it the name lodepng.c or lodepng.cpp (or .cc) depending on your usage
1267 If you want to start using LodePNG right away without reading this doc, get the
1268 examples from the LodePNG website to see how to use it in code, or check the
1271 LodePNG is simple but only supports the basic requirements. To achieve
1272 simplicity, the following design choices were made: There are no dependencies
1276 the colors of the raw image are always RGB or RGBA, no matter what color type
1277 the PNG file uses. To read and write files, there are simple functions to
1278 convert the files to/from buffers in memory.
1282 over network (it requires all the image data to be available before decoding can
1288 The following features are supported by the decoder:
1291 or the same color type as the PNG
1292 *) encoding of PNGs, from any raw image to 24- or 32-bit color, or the same color type as the raw i…
1294 *) loading the image from harddisk or decoding it from a buffer from other sources than harddisk
1302 *) the following chunks are supported by both encoder and decoder:
1306 IEND: the final chunk
1323 The following features are not (yet) supported:
1327 *) The hIST and sPLT public chunks are not (yet) supported but treated as unknown chunks
1333 The C version uses buffers allocated with alloc that you need to free()
1335 using a struct from the C version to avoid exploits and memory leaks.
1337 The C++ version has extra functions with std::vectors in the interface and the
1341 the additional C++ code is in "#ifdef __cplusplus" blocks that make C-compilers
1342 ignore it, and the C code is made to compile both with strict ISO C90 and C++.
1344 To use the C++ version, you need to rename the source file to lodepng.cpp
1347 To use the C version, you need to rename the source file to lodepng.c (instead
1357 When using LodePNG, care has to be taken with the C version of LodePNG, as well
1358 as the C-style structs when working with C++. The following conventions are used
1361 -if a struct has a corresponding init function, always call the init function when making a new one
1362 -if a struct has a corresponding cleanup function, call it before the struct disappears to avoid me…
1363 -if a struct has a corresponding copy function, use the copy function instead of "=".
1364 The destination must also be inited already.
1372 Most documentation on using the decoder is at its declarations in the header
1374 lodepng_decode32, and more advanced decoding can be done with the struct
1375 LodePNGState and lodepng_decode. For C++, all decoding can be done with the
1379 When using the LodePNGState, it uses the following fields for decoding:
1380 *) LodePNGInfo info_png: it stores extra information about the PNG (the input) in here
1381 *) LodePNGColorMode info_raw: here you can say what color mode of the raw image (the output) you wa…
1382 *) LodePNGDecoderSettings decoder: you can specify a few extra settings for the decoder to use
1387 After decoding, this contains extra information of the PNG image, except the actual
1388 pixels, width and height because these are already gotten directly from the decoder
1391 It contains for example the original color type of the PNG image, text comments,
1392 suggested background color, etc... More details about the LodePNGInfo struct are
1399 the resulting raw image to be. If this is different from the colortype of the
1400 PNG, then the decoder will automatically convert the result. This conversion
1404 By default, 32-bit color is used for the result.
1409 The settings can be used to ignore the errors created by invalid CRC and Adler32
1410 chunks, and to disable the decoding of tEXt chunks.
1413 is done, the resulting data will be as it was in the PNG (after decompression)
1414 and you'll have to puzzle the colors of the pixels together yourself using the
1415 color type information in the LodePNGInfo.
1423 Most documentation on using the encoder is at its declarations in the header
1425 lodepng_encode32, and more advanced decoding can be done with the struct
1426 LodePNGState and lodepng_encode. For C++, all encoding can be done with the
1430 Like the decoder, the encoder can also give errors. However it gives less errors
1431 since the encoder input is trusted, the decoder input (a PNG image that could
1434 When using the LodePNGState, it uses the following fields for encoding:
1435 *) LodePNGInfo info_png: here you specify how you want the PNG (the output) to be.
1436 *) LodePNGColorMode info_raw: here you say what color type of the raw image (the input) has
1437 *) LodePNGEncoderSettings encoder: you can specify a few settings for the encoder to use
1442 When encoding, you use this the opposite way as when decoding: for encoding,
1443 you fill in the values you want the PNG to have before encoding. By default it's
1444 not needed to specify a color type for the PNG since it's automatically chosen,
1445 but it's possible to choose it yourself given the right settings.
1447 The encoder will not always exactly match the LodePNGInfo struct you give,
1448 it tries as close as possible. Some things are ignored by the encoder. The
1449 encoder uses, for example, the following settings from it when applicable:
1450 colortype and bitdepth, text chunks, time chunk, the color key, the palette, the
1451 background color, the interlace method, unknown chunks, ...
1453 When encoding to a PNG with colortype 3, the encoder will generate a PLTE chunk.
1454 If the palette contains any colors for which the alpha channel is not 255 (so
1455 there are translucent colors in the palette), it'll add a tRNS chunk.
1460 You specify the color type of the raw image that you give to the input here,
1470 The following settings are supported (some are in sub-structs):
1471 *) auto_convert: when this option is enabled, the encoder will
1472 automatically choose the smallest possible color mode (including color key) that
1473 can encode the colors of all pixels without information loss.
1474 *) btype: the block type for LZ77. 0 = uncompressed, 1 = fixed huffman tree,
1479 *) windowsize: the window size used by the LZ77 encoder (1 - 32768). Has value
1481 *) force_palette: if colortype is 2 or 6, you can make the encoder write a PLTE
1484 *) add_id: add text chunk "Encoder: LodePNG <version>" to the image.
1486 zTXt chunks use zlib compression on the text. This gives a smaller result on
1494 An important thing to note about LodePNG, is that the color type of the PNG, and
1495 the color type of the raw image, are completely independent. By default, when
1496 you decode a PNG, you get the result as a raw image in the color type you want,
1497 no matter whether the PNG was encoded with a palette, grayscale or RGBA color.
1498 And if you encode an image, by default LodePNG will automatically choose the PNG
1499 color type that gives good compression based on the values of colors and amount
1500 of colors in the image. It can be configured to let you control it instead as
1504 It can convert from almost any color type to any other color type, except the
1506 palette when the palette doesn't have a required color is not supported. This is
1508 reduction algorithm that is beyond the scope of a PNG encoder (yes, RGB to gray
1512 By default, when decoding, you get the raw image in 32-bit RGBA or 24-bit RGB
1513 color, no matter what color type the PNG has. And by default when encoding,
1514 LodePNG automatically picks the best color model for the output PNG, and expects
1515 the input image to be 32-bit RGBA or 24-bit RGB. So, unless you want to control
1516 the color format of the images yourself, you can skip this chapter.
1522 as well as palettized color modes. After the zlib decompression and unfiltering
1523 in the PNG image is done, the raw pixel data will have that color type and thus
1524 a certain amount of bits per pixel. If you want the output raw image after
1527 The PNG specification gives the following color types:
1535 Bit depth is the amount of bits per pixel per color channel. So the total amount
1541 As explained in the sections about the encoder and decoder, you can specify
1542 color types and bit depths in info_png and info_raw to change the default
1545 If, when decoding, you want the raw image to be something else than the default,
1546 you need to set the color type and bit depth you want in the LodePNGColorMode,
1547 or the parameters colortype and bitdepth of the simple decoding function.
1549 If, when encoding, you use another color type than the default in the raw input
1550 image, you need to specify its color type and bit depth in the LodePNGColorMode
1551 of the raw image, or use the parameters colortype and bitdepth of the simple
1554 If, when encoding, you don't want LodePNG to choose the output PNG color type
1555 but control it yourself, you need to set auto_convert in the encoder settings
1556 to false, and specify the color type you want in the LodePNGInfo of the
1560 If the input and output color type differ (whether user chosen or auto chosen),
1561 LodePNG will do a color conversion, which follows the rules below, and may
1565 -the decoder converts from PNG to raw image
1566 -the encoder converts from raw image to PNG
1567 -the colortype and bitdepth in LodePNGColorMode info_raw, are those of the raw image
1568 -the colortype and bitdepth in the color field of LodePNGInfo info_png, are those of the PNG
1569 -when encoding, the color type in LodePNGInfo is ignored if auto_convert
1571 -when decoding, the color type in LodePNGInfo is set by the decoder to that of the original
1572 PNG image, but it can be ignored since the raw image has the color type you requested instead
1573 -if the color type of the LodePNGColorMode and PNG image aren't the same, a conversion
1574 between the color types is done if the color types are supported. If it is not
1575 supported, an error is returned. If the types are the same, no conversion is done.
1578 the raw image correctly before encoding.
1579 -both encoder and decoder use the same color converter.
1581 The function lodepng_convert does the color conversion. It is available in the
1582 interface but normally isn't needed since the encoder and decoder already call
1587 the result will look ugly because only the red channel is taken (it assumes all
1588 three channels are the same in this case so ignores green and blue). The reason
1591 -anything to palette when the palette does not have an exact match for a from-color
1597 -anything to a palette, as long as the palette has the requested colors in it
1602 -In the encoder, you can make it save a PNG with any color type by giving the
1603 raw color mode and LodePNGInfo the same color mode, and setting auto_convert to
1605 -In the decoder, you can make it store the pixel data in the same color type
1606 as the PNG has, by setting the color_convert setting to false. Settings in
1612 In the PNG file format, if a less than 8-bit per pixel color type is used and the scanlines
1614 scanline starts at a fresh byte. But that is NOT true for the LodePNG raw input and output.
1615 The raw input image you give to the encoder, and the raw output image you get from the decoder
1616 will NOT have these padding bits, e.g. in the case of a 1-bit image with a width
1617 of 7 pixels, the first pixel of the second scanline will the 8th bit of the first byte,
1618 not the first bit of a new byte.
1624 for any other color format. The 16-bit values are stored in big endian (most
1625 significant byte first) in these arrays. This is the opposite order of the
1628 LodePNG always uses big endian because the PNG file format does so internally.
1631 colors, the order in which you store R, G, B and A, and so on. Supporting and
1632 converting to/from all that is outside the scope of LodePNG.
1634 This may mean that, depending on your use case, you may want to convert the big
1637 anyway, but it means you cannot simply cast the unsigned char* buffer to an
1647 The meaning of the LodePNG error values can be retrieved with the function
1648 lodepng_error_text: given the numerical error code, it returns a description
1649 of the error in English as a string.
1651 Check the implementation of lodepng_error_text to see the meaning of each code.
1653 It is not recommended to use the numerical values to programmatically make
1654 different decisions based on error types as the numbers are not guaranteed to
1663 editor that should follow the rules about handling of unknown chunks, or if your
1664 program is able to read other types of chunks than the ones handled by LodePNG,
1665 then that's possible with the chunk functions of LodePNG.
1667 A PNG chunk has the following layout:
1677 If you have a buffer containing the PNG image data, then the first chunk (the
1678 IHDR chunk) starts at byte number 8 of that buffer. The first 8 bytes are the
1679 signature of the PNG and are not part of a chunk. But if you start at byte 8
1680 then you have a chunk, and can check the following things of it.
1683 exploits, always make sure the buffer contains all the data of the chunks.
1684 When using lodepng_chunk_next, make sure the returned value is within the
1689 Get the length of the chunk's data. The total chunk length is this length + 12.
1694 Get the type of the chunk or compare if it's a certain type
1700 Check if the chunk is critical in the PNG standard (only IHDR, PLTE, IDAT and IEND are).
1701 Check if the chunk is private (public chunks are part of the standard, private ones not).
1702 Check if the chunk is safe to copy. If it's not, then, when modifying data in a critical
1703 chunk, unsafe to copy chunks of the old image may NOT be saved in the new one if your
1709 Get a pointer to the start of the data of the chunk.
1714 Check if the crc is correct or generate a correct one.
1719 Iterate to the next chunk. This works if you have a buffer with consecutive chunks. Note that these
1720 functions do no boundary checking of the allocated data whatsoever, so make sure there is enough
1721 data available in the buffer to be able to go to the next chunk.
1727 These functions are used to create new chunks that are appended to the data in *out that has
1728 length *outsize. The append function appends an existing chunk to the new data. The create
1729 function creates a new chunk with the given parameters and appends it. Type is the 4-letter
1730 name of the chunk.
1735 The LodePNGInfo struct contains fields with the unknown chunk in it. It has 3
1737 the ones that come before the PLTE chunk, the ones that come between the PLTE
1738 and the IDAT chunks, and the ones that come after the IDAT chunks.
1739 It's necessary to make the distinction between these 3 cases because the PNG
1740 standard forces to keep the ordering of unknown chunks compared to the critical
1743 info_png.unknown_chunks_data[0] is the chunks before PLTE
1744 info_png.unknown_chunks_data[1] is the chunks after PLTE, before IDAT
1745 info_png.unknown_chunks_data[2] is the chunks after IDAT
1747 The chunks in these 3 buffers can be iterated through and read by using the same
1748 way described in the previous subchapter.
1750 When using the decoder to decode a PNG, you can make it store all unknown chunks
1751 if you set the option settings.remember_unknown_chunks to 1. By default, this
1754 The encoder will always encode unknown chunks that are stored in the info_png.
1756 use lodepng_chunk_append or lodepng_chunk_create to the chunk data in
1760 LodePNG add a bKGD chunk, set background_defined to true and add the correct
1767 No libraries other than the current standard C library are needed to compile
1768 LodePNG. For the C++ version, only the standard C++ library is needed on top.
1769 Add the files lodepng.c(pp) and lodepng.h to your project, include
1774 If performance is important, use optimization when compiling! For both the
1777 Make sure that LodePNG is compiled with the same compiler of the same version
1778 and with the same settings as the rest of the program, or the interfaces with
1795 The Mingw compiler (a port of gcc for Windows) should be fully supported by
1802 where it wants to use a non-standard function fopen_s instead of the standard C
1807 This is not standard C++ and will not be added to the stock LodePNG. You can
1822 try to fix it if the compiler is modern and standards compliant.
1828 This decoder example shows the most basic usage of LodePNG. More complex
1829 examples can be found on the LodePNG website.
1851 …//the pixels are now in the vector "image", 4 bytes per pixel, ordered RGBARGBA..., use it as text…
1878 A quick reference of some settings to set on the LodePNGState
1922 The version number of LodePNG is the date of the change given in the format
1928 Not all changes are listed here, the commit history in github lists more:
1932 *) 13 jun 2022: added support for the sBIT chunk.
1936 not the core part of PNG decoding/decoding and is platform dependent).
1938 *) 06 mar 2020: simplified some of the dynamic memory allocations.
1957 the limits of pure C90).
1970 prefix for the custom allocators and made it possible with a new #define to
1985 but it is cleaner now imho and functionality remains the same. Also fixed
1986 several bugs and shrunk the implementation code. Made new samples.
1987 *) 6 nov 2011: (!) By default, the encoder now automatically chooses the best
1988 PNG color model and bit depth, based on the amount and type of colors of the
1990 *) 9 okt 2011: simpler hash chain implementation for the encoder.
1992 *) 23 aug 2011: tweaked the zlib compression parameters after benchmarking.
1993 A bug with the PNG filtertype heuristic was fixed, so that it chooses much
1997 *) 16 aug 2011: made the code less wide (max 120 characters per line).
2007 Reorganized the documentation and the declaration order in the header.
2009 *) 05 jul 2010: fixed bug thanks to warnings in the new gcc version.
2012 read by ignoring the problem but windows apps couldn't.
2021 Also various fixes, such as in the deflate and the padding bits code.
2026 Having LodePNG be pure ISO C90 makes it more portable. The C and C++ code
2035 *) 02 jun 2007: made the encoder add a tag with version by default
2036 *) 27 may 2007: zlib and png code separated (but still in the same file),
2041 *) 24 apr 2007: changed the license from BSD to the zlib license
2046 Fixed a bug where the end code of a block had length 0 in the Huffman tree.
2048 and supported by the encoder, resulting in smaller PNGs at the output.
2049 *) 27 jan 2007: Made the Adler-32 test faster so that a timewaste is gone.
2052 *) 21 jan 2007: (!) Totally changed the interface. It allows more color types
2053 to convert to and is more uniform. See the manual for how it works now.
2054 *) 07 jan 2007: Some cleanup & fixes, and a few changes over the last days:
2056 at last made the decoder give errors for incorrect Adler32 or Crc.
2060 *) 28 dec 2006: Added "Settings" to the encoder.
2061 *) 26 dec 2006: The encoder now does LZ77 encoding and produces much smaller files now.
2062 Removed some code duplication in the decoder. Fixed little bug in an example.
2064 Fixed a bug of the decoder with 16-bit per color.
2066 *) 09 okt 2006: Encoder class added. It encodes a valid PNG image from the
2071 *) 29 jul 2006: (!) Changed the interface: image info is now returned as a
2073 *) 28 jul 2006: Cleaned the code and added new error checks.
2075 *) 23 jun 2006: Added SDL example in the documentation in the header, this
2076 example allows easy debugging by displaying the PNG and its transparency.
2085 in LodePNG namespace. Changed the order of the parameters. Rewrote the
2086 documentation in the header. Renamed files to lodepng.cpp and lodepng.h
2097 decoder, feel free to send it and I'll use it to find and fix the problem.
2099 My email address is (puzzle the account and domain together with an @ symbol):