4 ms·

> I'm going to use it local with Electron Interesting. I also have a use case for this though I wasn't sure how easy it would be to bundle something like GM w

> I'm going to use it local with Electron Interesting. I also have a use case for this though I wasn't sure how easy it would be to bundle something like GM with my Electron app. Have you any insights on this? I'm targeting both Win and Mac.

mikewhy 10y ago
Windows can use the compiled binary, Mac will need a static build. If you're using asar packages in your final app make sure it extracts those binaries then do a child_process.spawn
- teleclimber 10y ago
  Thank you for the info. I'm looking for a link with all the details but I haven't found one so far. If you have that I would appreciate you sharing. Thanks!
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 ago
  Now this is real serendipity! I was guessing that I'd have a difficult time with this integration. Jumping straight to your recommendation.
  - fenomas 10y ago
    Well, 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 ago
    Jimp 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 ago
      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.
      - teleclimber 10y ago
        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 https://github.com/eugeneware/jpeg-js/issues
        hcho 10y ago
        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.
- thomasz 10y ago
  You can drive graphicsmagick via stdin/stout if you start it with the batch command, and avoid writing temporary files.
  - fenomas 10y ago
    Yes, 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).

mikewhy 10y ago

Windows can use the compiled binary, Mac will need a static build. If you're using asar packages in your final app make sure it extracts those binaries then do a child_process.spawn

teleclimber 10y ago
Thank you for the info. I'm looking for a link with all the details but I haven't found one so far. If you have that I would appreciate you sharing. Thanks!

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 ago
Now this is real serendipity! I was guessing that I'd have a difficult time with this integration. Jumping straight to your recommendation.
- fenomas 10y ago
  Well, 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 ago
  Jimp 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 ago
    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.
    - teleclimber 10y ago
      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 https://github.com/eugeneware/jpeg-js/issues
      - hcho 10y ago
        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.
thomasz 10y ago
You can drive graphicsmagick via stdin/stout if you start it with the batch command, and avoid writing temporary files.
- fenomas 10y ago
  Yes, 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).