Please be very careful when using less popular C/C++ image parsing libraries on anything that is user-controlled or that comes from the Internet.

Image, multimedia, and archive parsing are notoriously prone to security bugs. In fact, so are most other types of complex parsing. There are months of researcher work and decades of CPU time that went into auditing and fuzzing libraries such as libpng or libjpeg-turbo, identifying and fixing lots of vulnerabilities. The same isn't true for libraries with much smaller following, especially if their documentation doesn't contain any discussion of security risks and countermeasures taken.

And a quick glance shows that the code isn't written in a terribly obvious and defensive manner. For example, just by skimming you can spot loads and loads of unchecked arithmetic. How can you know none of that can be exploited? The code doesn't do a lot to assure you of that.

I'm reminded of stb_image... https://github.com/nothings/stb/blob/master/stb_image.h

+1 for stb_image

its a very good cross platform bit of code. even though it has some annoying compiler warnings, i've managed to get this to work just fine on Windows, Mac, Linux (ubuntu, CentOS, RHEL at least...), Android (even the obscure mips configs), iOS, Windows Phone 8, Windows 8 Store and other platforms that must remain nameless.

Well this is a little strange to link. I've been using this small library for years, last update was 2005. Hardly 'news'

The linked homepage states that the latest update was in 2012: "Revamped interface with more consistent names, rewrote some parts, bugfixes.".

Now it says "2014: Moved the code to GitHub"

Small image libraries are fun!

jpeg writing & loading: https://code.google.com/p/jpeg-compressor/

jpeg loading: https://code.google.com/p/picojpeg/

jpeg loading: https://code.google.com/p/jpgd/

OpenEXR writing: https://github.com/aras-p/miniexr/blob/master/miniexr.cpp

PNG writing (and zlib + ZIP file handling): https://code.google.com/p/miniz/

Newest version of miniz reads and writes zip64 archives and is part of vogl project: https://github.com/ValveSoftware/vogl/tree/master/src/voglco...

And of course already mentioned stb_image: https://github.com/nothings/stb/blob/master/stb_image.h

I wrote a png writer[1] a few years ago with no dependencies that adds about 3k to the resulting binary.

It doesn't deflate, but it's useful if you need to take a screenshot where space is at a premium.

[1]: http://geocar.sdf1.org/pngw.tgz

Funny that this shows up today, as what I've spent time on today is to create an image reader for sending images over the NFC protocol.

I've been so frustrated today by trying to get libpng to work, but landed on this library one hour ago and now everything just works sweet! :-)

Umm...

As is mentioned elsewhere in the thread: this does not seem to be secure software. As such, think twice about using this: do you really want anyone within NFC range to be able to exploit your app?

Thanks for the warning.

Of course using a secure library is preferred. Though it's really hard to use something that isn't very well documented and I just have a few months of experience working with C. Which is also a potential dangerous combination.

I found another library that wraps libpng https://github.com/nilx/io_png Maybe I could be more successful with that library.

Why are you having such trouble getting libpng to work? Is it the target environment or using the API?

Just had fun clicking on the other projects link and finding LodePaint and the esoteric languages and ... you go take a look yourself! :D

I don't want to sound rude, but based on the title, I understand that this has something to do with PNG files.

It might be worth putting a bit more details there.

I don't know if the URL has changed or something, but:

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

Or you mean the title here in HN? That's an unfortunate consequence of the "keep titles verbatim" rule.

> That's an unfortunate consequence of the "keep titles verbatim" rule

I fear that you're misunderstanding the rule a little. There's nothing wrong with including an explanatory phrase from a subtitle, or from the introductory sentence of the page, which is often a de facto subtitle. (We added that when we saw this title earlier today). What we're strict about avoiding is submitters rewriting titles to make their own point about the content, rather than preserving what the author wrote.

Sorry, might not had been clear enough - I had meant HN title. I understand the "keep titles verbatim" rules, but on the other hand:

Show HN: tool

vs

Show HN: tool (fancy cross-platform XYZ processor)

With that many number of tools being released and advertised I really think that second one is way more informative, while still being verbatim.