lvandeve / lodepng Goto Github PK

Greetings!

I'm experiencing some odd behaviour with LodePNG and I was wondering if you might be able to help me. I'll be honest- I have no idea if this is even a problem with LodePNG, or my compiler (Clang/LLVM 5.1) or both.

Anyways, I've got a really simple utility here that I use to do some math stuff on the pixel values directly. I'm using the C equivalent of the code found in example_reencode.cpp to load a PNG, perform some math functions on the pixel values, and then dump the entire thing back to disk.

Here's where things get weird- the program works fine with any input PNG created by a program other then LodePNG. It runs, processes the file, dumps it to disk, and quits successfully. If I run my program on that output file as the input file, LodePNG seems to load part of the image into memory- but then the the pixels start returning all zeros for their values around 40% of the way through, and eventually the entire thing crashes with EXEC_BAD_ACCESS.

I've tried compiling example_reencode.cpp and running that on a series of files (constantly feeding the output back into the input and running the program again) and that seems to work just fine. Likewise, I've discovered if I set state.decoder.color_convert to 1 (instead of 0), then my program runs fine without crashing (but I don't want any color conversion!).

I can post the source code somewhere if you'd like to take a look at it, though there's nothing terribly complicated about it. I'm just iterating through the pixels individually like so:

for (unsigned int y = 0; y < height; y ++)
{
    for (unsigned int x = 0; x < width; x ++)
    {
        unsigned int r = image[4 * width * y + 4 * x + 0];
        unsigned int g = image[4 * width * y + 4 * x + 1];
        unsigned int b = image[4 * width * y + 4 * x + 2];
        unsigned int a = image[4 * width * y + 4 * x + 3];

        /* Do math stuff here with r, g, b, and a */

        image[4 * width * y + 4 * x + 0] = r;
        image[4 * width * y + 4 * x + 1] = g;
        image[4 * width * y + 4 * x + 2] = b;
        image[4 * width * y + 4 * x + 3] = a;
    }
}

Is it something I'm doing, or is there a weird glitch in the C version of LodePNG? The fact that things don't go sideways if I set state.decoder.color_convert to 1 makes me think that it has something to do with the colour conversion code, but alas the majority of LodePNG is somewhat beyond my understanding :(.

Thanks in advance for any assistance you can provide!
-CMPX

I'm using Firefox, which refuses to load the HTTPS version of your homepage:

lodev.org uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
The certificate is only valid for server54.hostpoint.ch
(Error code: sec_error_unknown_issuer)

After this is fixed, I suggest changing README.md:6 to the https version.

Ideally, grep -rn http: would yield no match within the sourcecode. However, the existing references (w3.org and gzip.org) do not support HTTPS yet, so there's nothing to change in lodepng (not yet).

in file lodepng/examples/example_bmp2png.cpp. Line 93-97 wrong R/G/B/A order

should be :
image[newpos + 0] = bmp[bmpos + 2];
image[newpos + 1] = bmp[bmpos + 1];
image[newpos + 2] = bmp[bmpos + 0];
image[newpos + 3] = bmp[bmpos + 3];
when I use this it can work well.

We would like to depend on lodepng for a project and would like to be able to check out specific tagged commits so that new changes to master will not necessarily break our build. We really enjoy using this project, thank you for your work.

Could I change color type image from RGB to RGBA with

unsigned lodepng_decode(unsigned char** out, unsigned* w, unsigned* h,
LodePNGState* state,
const unsigned char* in, size_t insize);

Thank so much.

Need to check its compatible with MIT license.

Hi,

I cannot get it to work with saving a 16 bit RGB image. I end up with 8 bit RGB. Upon decoding the file again it gives me state.raw_info.bitdepth == 8 .
I tried with : lodepng::encode(pstr, VImage, m_x, m_y, LCT_RGB, 16U);
and also using state:
lodepng::State state;
state.info_raw.bitdepth = 16U;
state.info_raw.colortype = LCT_RGB;
state.encoder.auto_convert = 1;
state.info_png.color.bitdepth = 16;
state.info_png.color.colortype = LCT_RGB;

			std::vector<unsigned char> png;
			
			unsigned error = lodepng::encode(png, Vimage, m_x, m_y, state);
		
			if (!error) lodepng::save_file(png, pstr);

It's like the most first world problem in the history of the universe, but it'd be cool if you'd change the input and output arrays from unsigned char to uint8_t. they're exactly the same underneath the covers, plus you're not using it as a char, but as an unsigned int.

Anyway, feel free to decline this request, because it doesn't really matter, it'd just be nice.

I think this flag should be added. Just as it is with zlib, someone could use LodePNG and CRC32 routines in same project, so no point in duplicating the code and the tables.

Hi Gabor

I am so happy that there is now PNG support! I do see something that looks like a bug and I am reporting it here, but overall - yay, great job!

So...

I followed the steps in https://littlevgl.com/blog/50/use-png-images-in-littlevgl and got the same visual results (the 4 dice are displayed over the blueish background, with transparency).

However I a get this output (I put printf's to the decoder functions to see when they are called. This is ran on the PC btw):

png_decoder_info called
png_decoder_info called
png_decoder_open called
png_decoder_close called
png_decoder_info called
png_decoder_open called
png_decoder_close called
png_decoder_info called
png_decoder_open called
png_decoder_close called
png_decoder_info called
png_decoder_open called
png_decoder_close called

As you can see, firstly png_decoder_info is called once and then the entire sequence (info-open-close) is repeated 4 times. This does not seem correct?

I am attaching my code, although it is pretty much the same as the tutorial...

decoder.cc.txt
main.c.txt

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.

@lvandeve is it possible to move #define VERSION_STRING "20141126" from implementation file into lodepng.h (for example as LODEPNG_VERSION_STRING) so it can be used by applications using your library?

Thanks, I use Python, so i use lodepng.c and lodepng.h to create .so file by gcc on ubuntu, then it create liblodepng.so .
The order is 'gcc lodepng.c -I ./ -fPIC -shared -o liblodepng.so'
but when i use this liblodepng.so, it report a bug,

The bug is :
bash: line 1: 14557 Segmentation fault (core dumped) env "PYTHONUNBUFFERED"="1" "PYTHONPATH"="/tmp/pycharm_project_500:/root/.pycharm_helpers/pycharm_matplotlib_backend" "PYCHARM_HOSTED"="1" "JETBRAINS_REMOTE_RUN"="1" "PYCHARM_MATPLOTLIB_PORT"="52649" "PYTHONIOENCODING"="UTF-8" '/home/ubuntu/env/env_fun/bin/python3.5' '-u' '/tmp/pycharm_project_500/png/test.py'

i don't why, the zip file it contains liblodepng.so
liblodepng.zip

lodepng can work without libc. Maybe, wrap "strlen", "qsort" and "memset" functions like "lodepng_malloc"?

The current implementation is getting enough dirty:
https://github.com/DeXP/dxPmdxConverter/blob/master/bmpconvert.c

I have a question about the name: Why is this called 'lodepng'? Shouldn't it be 'loadpng'?

The loop conditions seem odd in this utility function.

 unsigned long readBitsFromReversedStream(size_t& bitp, const unsigned char* bits, unsigned long nbits)
  {
    unsigned long result = 0;
    for(size_t i = nbits - 1; i < nbits; i--) result += ((readBitFromReversedStream(bitp, bits)) << i);
    return result;
  }

It's an extension for stereoscopic support in PNG.

When encoding images with alpha information that could otherwise use a palette, alpha information is discarded.

My specific use case: I open an image with lodepng_decode32_file, then based on its luminance value I output a white color with only the alpha set to said luminance value. Using lodepng_encode32_file then outputs a plain white palletized image (P8).

I was able to fix this changing

palette_ok = n <= 256 && (n * 2 < w * h) && prof.bits <= 8;

to

palette_ok = !prof.alpha && n <= 256 && (n * 2 < w * h) && prof.bits <= 8;

in the lodepng_auto_choose_color function. The output is then in A8L8.

I'm not entirely sure if this is considered a bug or a feature :). But since I'm expecting the encode to be a lossless process, I'm reporting this.

Also thanks so much for this library, it's a great and compact alternative to libpng!

Would it be possible to add a streaming api where you load the source data in (my understanding of png compression is that you need the whole image do the compression) and then get chunks of data back.

Somehow incrementally calling a function that returns a bit more of the output, and at last returns that it's done.

Would this be feasible or am I overlooking something in how png works that would make this bad?

hi,
this is more of a suggestion from you rather than an issue. sorry for posting in issue but did not a way to contact you.
i want to resize the pixel image or bitmap image, but unable to find the function to do so in your library. i am unable to use any other library due to compatibility issues with my hardware.
Can you please guide me towards the same or if any function that exist in your library which can help me achieve my goal.
Requirement : i have png of (greater than 4mb) i want a bmp file of it which is of 100*100 dimention.
please help me its really urgent.

thanks in advance

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.

Groetjes,

The cool thing would be to avoid SDL and OPENGL for LODEPNG, as well C++ (g++, cmake,...).

Would it be possible to give a LODEPNG for X11 and plain C (if possible, lot of work I know,...)?

thank you for your efforts creating light libraries for everyone and every usable applications !!!

Can we use Multi-core / OpenCL to accelerate compression?

LCT_GREY equivalent but with Little Endian

Creating a x64 target with MS compilers report several warnings. On a x64 target variable type "unsigned" is 32bit whereas "size_t" is 64bit wide causing most of the warnings.

Hi,
I'm using standard zlib to load pngs via lodepng, i find it would be much easier to provide uncompressed size for custom zlib_decompress to uncompress data, like this :

// decodeGeneric, line 4720 in lodepng.cpp
scanlines.size = predict; // <--- add this to init the size with predict (the uncompressed size) instead of 0
state->error = zlib_decompress(&scanlines.data, &scanlines.size, idat.data,
                                   idat.size, &state->decoder.zlibsettings);

what do you think? what's the correct way to load pngs with custom zlib?

Thank you.

wrong color to decode this file, please check it.

Hi Lode,
It's probably out of the scope noob question and maybe not an real issue about the lodepng itself. I'm trying to add This library as deflate compressor in ZopfliPNG instead of Zopfli. I don't even know if I'm doing this in the right way:

   unsigned CustomPNGDeflate(unsigned char** out, size_t* outsize,
   const unsigned char* in, size_t insize,
   const LodePNGCompressSettings* settings) {

   int compression_level = 12;
   struct libdeflate_compressor* compressor;
   compressor = libdeflate_alloc_compressor(compression_level);
   libdeflate_deflate_compress(compressor, in, insize, out, *outsize);
   libdeflate_free_compressor(compressor);
   return 0;
}

This compile well, but ZopfliPNG is corrupting all images (full black pixels) probably because it's not used as it should be. Any help will be appreciated !

After using "lodepng_state_init", then "lodepng_inspect", there is not enough information to know if an 8-bit image has alpha or not. For 8-bit images, "lodepng_can_have_alpha" will only give correct results after the image has been completely decoded, which is usually too late for when you want to see if it needs an alpha channel or not.

"lodepng_has_palette_alpha" should have features added to it. It should check if the image is palettized, then check if the palette has been loaded or not, and if it hasn't been loaded, load the "PLTE" and "tRNS" chunks so it will have a palette available with possible alpha channel. That would fix the issue with "lodepng_can_have_alpha" yielding incorrect results.

Edit:
Looks like lodepng_has_palette_alpha doesn't have any handles to the input file, so it can't load it. I guess there needs to be another function to preload a palette if it exists. Possibly stick this into the Inspect function if you don't want to add anything new to the API.

Hi,

I wonder why isn't there any recipe to generate a static or dynamic library for this library? Should we add one?

Greetings lodepng developers and contributors,

We’re reaching out because your project is an important part of the open source ecosystem, and we’d like to invite you to integrate with our fuzzing service, OSS-Fuzz. OSS-Fuzz is a free fuzzing infrastructure you can use to identify security vulnerabilities and stability bugs in your project. OSS-Fuzz will:

• Continuously run all the fuzzers you write.

• Alert you when it finds issues.

• Automatically close issues after they’ve been fixed by a commit.

Many widely used open source projects like OpenSSL, FFmpeg, LibreOffice, and ImageMagick are fuzzing via OSS-Fuzz, which helps them find and remediate critical issues.

Even though typical integrations can be done in < 100 LoC, we have a reward program in place which aims to recognize folks who are not just contributing to open source, but are also working hard to make it more secure.

We want to stress that anyone who meets the eligibility criteria and integrates a project with OSS-Fuzz is eligible for a reward.

To help you getting started, we attached our internal fuzzer for your project that you are welcome to use directly, or to use it as a starting point.

If you're not interested in integrating with OSS-Fuzz, it would be helpful for us to understand why—lack of interest, lack of time, or something else—so we can better support projects like yours in the future.

If we’ve missed your question in our FAQ, feel free to reply or reach out to us at [email protected].

Thanks!

Tommy
OSS-Fuzz Team

#include <cstddef>
#include <cstdint>
#include <cstdlib>
#include <string>
#include <vector>
#include "lodepng.h"

namespace {

LodePNGColorType SelectColorType(const uint8_t** data, size_t* size) {
  uint8_t color_type_selector = 0;
  if (*size >= 1) {
    color_type_selector = *data[0];
    *data += 1;
    *size -= 1;
  }
  const std::vector<LodePNGColorType> colorTypes{LCT_GREY, LCT_RGB, LCT_PALETTE,
                                                 LCT_GREY_ALPHA, LCT_RGBA};
  return colorTypes.at(color_type_selector % colorTypes.size());
}

}  // namespace

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
  if (size == 0) {
    return EXIT_SUCCESS;
  }
  const LodePNGColorType wantColorType = SelectColorType(&data, &size);

  const unsigned char* buffer = reinterpret_cast<const unsigned char*>(data);

  LodePNGState lp{};
  lodepng_state_init(&lp);

  unsigned int lp_w{};
  unsigned int lp_h{};
  const unsigned inspect_err = lodepng_inspect(&lp_w, &lp_h, &lp, buffer, size);
  if (inspect_err != 0) {
    lodepng_state_cleanup(&lp);
    return EXIT_SUCCESS;
  }

  std::vector<unsigned char> outBuffer{};
  unsigned int w{};
  unsigned int h{};
  lodepng::decode(outBuffer, w, h, buffer, wantColorType);

  lodepng_state_cleanup(&lp);
  return EXIT_SUCCESS;
}

If you write 16 bit grayscale pngs the output is corrupted. 8 bit seems to work fine.

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.

Hi again.
I noticed that LodePNG always allocates its own memory to hold decoded results. I'd like to have the possibility to provide my own buffer to receive decoded data.
Currently I made a little makeshift patch so that providing non-null "out" will prevent allocation, but it's hardly a proper solution.

I have an application where I need to read .png files as binary data. The png files are in 8-bit rgba format, and I'm having to convert them to a proprietary format for use on a company video display. I read the files using lodepng_decode32_file().

This has been working fine with most png files that I've gotten, but when my co-worker gives me png files which are generated from Adobe Photoshop, the binary data isn't correct; for example, in one file, the first 4 pixels were:
before: 00000: 3A F8 55 00 3A F8 55 00 3A F8 55 00 3A F8 55 00
but the data was actually a grey value (i.e., R=G=B).
When I re-saved the file using a different program (Faststone Image Viewer), and then read the resulting file, I got:
before: 00000: 80 80 80 00 80 80 80 00 80 80 80 00 80 80 80 00

I was originally using a 2013 build of lodepng, but upgraded to current code, unfortunately with same results... Do you have any idea what is wrong here?? Is there some setting that I need to change in order to read the Photoshop png files correctly??

I can't seem to be able to write 32k PNGs. Affinity Photo and Photoshop both seem to be able to write PNGs with up to 32767x32767 in both 8bit and 16bit modes so it seems to be supported by the spec. 16k PNGs seem to work.

EDIT: it's worth mentioning that writing a 30000x30000 greyscale+alpha texture seems to work.

Pillow/PIL currently has a bug which prevents it from reading text chunk data if that data is stored in the PNG file after the first IDAT chunk. lodepng always writes text chunks after the IDAT chunk so PIL will not read them. Since Pillow is a popular PNG reading package I wanted to report that you can
re-order the writing of chunks in the lodepng_encode() function so Pillow will read them.

I was trying to open a 38364 x 18372 pixel RGBA 8 bit png and got the 92 error.
I tracked it to this line: if(numpixels > 268435455) CERROR_RETURN(state->error, 92).
For testing purposes I removed it and tried to open the file again, and as far as I can tell it opened perferctly fine in my 64 bit application.

What I wonder is if this is something left from 32 bit limitations or if this is still relevant and I'm playing with fire? From cursory examination it seems that all important variables are size_t which are large enough on 64 bit compilations.

In the unit tests there's one test with "1-bit RGB" color:

colorConvertTest("11111111 11111111 11111111 00000000 00000000 00000000", LCT_RGB, 1, "10", LCT_GREY, 1);

I'm not sure if that test is valid. AFAIK PNG doesn't allow 1bpp in RGB mode.

There's disagreement between lodepng_get_raw_size() which calculates size for 1bpp, and getPixelColorRGBA8 which does not (the implementation assumes that only 8 and 16 are valid)

if(mode->colortype == LCT_RGB)
  {
    if(mode->bitdepth == 8)
    {
      *r = in[i * 3 + 0]; *g = in[i * 3 + 1]; *b = in[i * 3 + 2];
      if(mode->key_defined && *r == mode->key_r && *g == mode->key_g && *b == mode->key_b) *a = 0;
      else *a = 255;
    }
    else
    {
      *r = in[i * 6 + 0];
      *g = in[i * 6 + 2]; // out of bounds read?
      *b = in[i * 6 + 4];
      if(mode->key_defined && 256U * in[i * 6 + 0] + in[i * 6 + 1] == mode->key_r
         && 256U * in[i * 6 + 2] + in[i * 6 + 3] == mode->key_g
         && 256U * in[i * 6 + 4] + in[i * 6 + 5] == mode->key_b) *a = 0;
      else *a = 255;
    }
  }

Hi, thanks for LodePNG.

To make the custom allocator functionality (LODEPNG_NO_COMPILE_ALLOCATORS) useful to me, I need the lodepng_malloc/realloc/free functions to accept an extra void *user_arg argument.

I think this can be done without breaking the API by e.g.

unsigned lodepng_decode_memory_using(unsigned char** out, unsigned* w, unsigned* h,
                               const unsigned char* in, size_t insize,
                               LodePNGColorType colortype, unsigned bitdepth, void *allocator_arg)
{
    // normal implementation except using allocator_arg for lodepng_malloc, lodepng_free etc.
}

unsigned lodepng_decode_memory(unsigned char** out, unsigned* w, unsigned* h,
                               const unsigned char* in, size_t insize,
                               LodePNGColorType colortype, unsigned bitdepth)
{
    // wrapper that behaves like the default
    return lodepng_decode_memory_using(out, w, h, in, size, colortype, bitdepth, NULL);
}

#ifdef LODEPNG_COMPILE_ALLOCATORS
static void* lodepng_malloc(size_t size, void *user_arg)
{
    UNUSED(user_arg);
    return malloc(size);
}

However this would break the API for anyone already using custom allocators.

Would such a change, in principle, be accepted by you? If so I'm prepared to make the changes for you and send you a pull request. Many thanks!

I have a png file with a palette, and the palette contains duplicate colors. I read the file, passing

	state.info_raw.colortype = LCT_PALETTE
	state.info_raw.bitdepth = 8

to lodepng_decode. (I want both the value of each pixel, as a palette index, and the palette.) Unfortunately, lodepng_decode performs an unnecessary call to lodepng_convert, which causes the original palette indices to be lost.

The problem is this check in lodepng_color_mode_equal:

  /*if one of the palette sizes is 0, then we consider it to be the same as the
  other: it means that e.g. the palette was not given by the user and should be
  considered the same as the palette inside the PNG.*/
  if(1/*a->palettesize != 0 && b->palettesize != 0*/) {

In this case a->palettesize is 0, because I didn't pass a palette to lodepng_decode.
I don't know why this is commented out; the git log is uninformative. Uncommenting it fixes the bug for me but maybe it breaks something else.

Luckily there is a very easy workaround:

	state.decoder.color_convert = 0

I encountered the following error with the attached png and was able to reproduce it with the example_decode program.

error 30: chunk length too large, chunk broken off at end of file

I'm using the most recent version of lodepng from master branch.

commit 8a0f16a
Author: Lode Vandevenne [email protected]
Date: Thu Dec 22 13:46:52 2016 +0100

Update README.md

Gimp is able to read the file successfully so it seems like a potential decoding bug.

I get the following warnings when compiling on Windows for 64-bit:

lodepng.cpp(773) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
lodepng.cpp(1437) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
lodepng.cpp(1441) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
lodepng.cpp(1513) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data
lodepng.cpp(3458) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data
lodepng.cpp(4261) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data
lodepng.cpp(4309) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data
lodepng.cpp(4389) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data
lodepng.cpp(5329) : warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned int', possible loss of data

Everything seems to work fine, though...

I ran into your code on a university project and when compiling it with http://clang-analyzer.llvm.org running alongside the compilation, it spit out a handful of issues. If you want to, I can report them each on their own, but it might be faster if you just run this yourself.

It seems only 8 bit buffers are supported. But, 16 bit needs unsigned ints or similar, if the 16 bit is already available to the user, who doesn't want to downsample it to 8bit.

Hi, thank for a great library!

I was wondering if it would be possible to add LCT_ARGB to support storing the raw data with the order ARGB instead of RGBA. This is the format that cairo uses natively.

Having this would save me from doing the conversion in memory before hand, which I would guess is much slower.

Thanks!

Hi there! This is a great lib and all, however when i was modifying its memory management code i noticed that function static void lodepng_free(void* ptr) gets a null passed in a lot of times.

The best way to reproduce is to run example_4bit_palette.cpp example and put something like
if(!ptr) { printf("null ptr \n"); }
and see stuff fall into console. It does not cause crash or any consequences it looks like, but still I would like to point this out, because if this is unintentional its good to know how the code behaves. And maybe fix this.

version string = 20190210

Something like
lodepng_decode_file(&temp, &tempWidth, &tempHeight, filename, LCT_PALETTE, 8)
will properly get the index for each pixel in temp, but I can't find a simple way to get the palette that corresponds to these indices.

It seems the answer is to mirror the body of lodepng_decode_memory and grab the info before the lodepng_state_cleanup which isn't too bad, but a readily available function might help others with indexed musings.

Hello, I got error 56 at loading the attached png. it seems that info_raw.bitdepth is zero even when info_png.color says it's 8 and also the format doesn't check, info_raw.colortype say is LCT_GREY but
info_png.color says it's LCT_RGBA.

I'm using visual studio community 2015 in release config architecture x86.

Build error when there is no stdlib.
Better wap qsort(in line 798) with "lodepng_qsort", and wrap "free"(in line 5348) with "lodepng_free".