5 ms·

The level of serendipity in HN is absurd. This is exactly what I was going to search for today. I'm going to use it local with Electron.

by meira 10y ago

teleclimber 10y ago
> 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
olalonde 10y ago
And I was just debugging a "pixel cache allocation fail" bug with GM: https://github.com/aheckmann/gm/issues/598 https://github.com/aheckmann/gm/issues/598.

The level of serendipity in HN is absurd. This is exactly what I was going to search for today. I'm going to use it local with Electron.

by meira 10y ago

The level of serendipity in HN is absurd. This is exactly what I was going to search for today. I'm going to use it local with Electron.

teleclimber 10y ago

> 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

olalonde 10y ago

And I was just debugging a "pixel cache allocation fail" bug with GM: https://github.com/aheckmann/gm/issues/598 https://github.com/aheckmann/gm/issues/598.