Hacker News Reader

Comment by seandougall | Hacker News Reader

I (and a number of other folks) have also run into an enormous memory leak, apparently originating in jpeg-js, when using jimp. On the order of "loading a 3MB file leaks 200MB of memory", which makes it unusable if you're at all RAM-constrained. Shame, because it has a lot of promise otherwise.

View on HN

Good to know. However I don't see any issues for this in the jpeg-js Github.[1]

The decoder.js script in jpeg-js is < 1000 loc, so I suspect this can be addressed if someone comes up with a reproducible case?

Edit: I'll happily try to do it if this isn't resolved by the time I get around to needing to use jimp / jpeg-js.

[1] https://github.com/eugeneware/jpeg-js/issues

On top of the memory issue, jimp format support seems limited. No gif support for example.

My personal favourite is node-canvas. It simply brings the HTML5 canvas api to node.

Does node-canvas allow you to select high fidelity algorithms over fast algorithms? A while ago, I wrote a crop tool using browser canvas, and found that the results of a scaling operation were unacceptable, due to its fast downsampling algorithm.

The gory details and a few attempts at higher quality scaling algorithm implementations are on SO: http://stackoverflow.com/questions/18922880/html5-canvas-res.... TL;DR: sending the image to the server and having GM scale it is faster and more reliable than your own scaling algorithm in single-threaded browser JS.

I think node canvas is a wrapper over cairo. It lets you set a quality value too. Whether cairo is comparable to GM is something I don't know.

Nice, I'm going to keep an eye on this, but I guess it will not be a huge problem because it will run single-user in a desktop machine.

Reply on news.ycombinator.com