Hi everyone, I wanted to share my PNG implementation in crystal: GitHub - SleepingInsomniac/png: PNG implementation in Crystal. I started working on it to support another project since I didn’t see an existing project with support for all the bit depths, color types, paletted images etc… It was a pretty fun learning experience, and I’m wondering what others think.
Looks like an awesome project!
I’ve been using stumpy png - mostly for outputting the results of neural networks in specs
I’d be interested in some performance comparisons. Stumpy feels quite slow to me (but still super useful)
I’ve also implemented a bunch of resizing and cropping algorithms you might find useful in your project
Thanks! I’ll take a look at those. I am planning on adding some additional methods like resizing and rotation. I have another project which is a simple SDL game engine with a some 2d drawing functions like Bézier curves, shape filling, etc. so I thought I might extract those to a separate shard and make it integrate nicely with the PNG library here.
Nice!!! I just updated my cr-image shard to use your crystal native implementation rather than the previous libspng
version for the png format Performance wise, it’s about the same in timeliness, but libspng
has a better memory footprint (see benchmark). Easily close enough that I prefer the crystal native implementation instead.
cr-image (like Pluto, which it started as a fork from) tries to prioritize performance. If Stumpy is feeling sluggish, maybe take a look at cr-image (or Pluto) instead? Ideally I want cr-image to be as feature-full for image processing as I can, partly as a great utility, and partly because I’ve been having a ton of fun learning about, well, image processing cr-image also contains some utility methods to convert from / to stumpy, if needed.
The bottleneck, especially in stumpypng, is the zlib call. There isn’t much you can do about speeding that up. I spent a day trying to eek more performance out of stumpy for a work project and while I was able to trim some fat, there is no getting around the zlib usage.
I noticed this does just about the same thing as stumpy in that regard. I’ll play around with it and see if there is any performance improvements to how it’s writing.