6 ms·
If the app uses JS, I recently did a bunch of image processing using the node GM wrapper ('gm' on npm), and it was generally a huge pain in the ass. I found tha
by fenomas 10y ago
If the app uses JS, I recently did a bunch of image processing using the node GM wrapper ('gm' on npm), and it was generally a huge pain in the ass. I found that I couldn't do the edits I needed in a single atomic call to gm, and I couldn't get the wrapper to pipe multiple calls together, so I wound up having to write and manage temp files, and it was all pretty hairy.
I later found a project called 'jimp', which is more or less similar to gm but written in pure JS, and which made it easy to chain calls together into nontrivial edits. Since it has no native dependencies it would probably be easier to bundle with electron as well. Presumably it's slower than gm of course (in my case that didn't matter, so I never looked back).
- meira 10y agoNow this is real serendipity! I was guessing that I'd have a difficult time with this integration. Jumping straight to your recommendation.
- fenomas 10y agoWell, YMMV but for me what took me several days with the gm wrapper, I had working in about 15 minutes with jimp. Now that I think about it, I recall that the gm wrapper had a very strange API, that greatly obscured what parameters got passed to gm underneath, and figuring out how that worked was a big part of the headache. With jimp, everything basically did what it said on the tin. I remember wondering why such a useful library wasn't more famous.
- teleclimber 10y agoJimp is something I had come across as well and played with a bit. FYI I wrote in my notes "dependency on jpeg-js is dog slow." I recommend some perf tests for your use case before jumping too far in.
- seandougall 10y agoI (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.
- teleclimber 10y agoGood 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 https://github.com/eugeneware/jpeg-js/issues
- hcho 10y agoOn 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.
- happyslobro 10y agoDoes 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-resize-downscale-image-high-quality 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.
- hcho 10y agoI 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.
- meira 10y agoNice, 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.
- thomasz 10y agoYou can drive graphicsmagick via stdin/stout if you start it with the batch command, and avoid writing temporary files.
- fenomas 10y agoYes, in retrospect I think much of my difficulty came from the node 'gm' wrapper being hard to use - it would probably have been easier to invoke gm directly (as a child_process or however that's normally done).