5 ms·

GraphicsMagick has been one of the hidden gems I've found over the years in my career. HN would probably mostly be interested in it for server-side application

by patio11 10y ago

GraphicsMagick has been one of the hidden gems I've found over the years in my career. HN would probably mostly be interested in it for server-side applications [+], but it is an absurdly useful thing to have sitting around your laptop, too, for those times when e.g. you've got a screenshot of something but a government/etc site will only take a file upload in pdf format. "gm convert foo.png foo.pdf" and you're done. [+] Really good for common "take an arbitrary user upload; grab info to crop it from your web app; crop and resize to appropriate dimensions" sorts of tasks.

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.
- 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.
pavlov 10y ago
Personally I find that Apple Preview has always been good enough for these tasks. It can also do a surprising amount of PDF editing: for example, you can draw annotations on pages (for highlights and signatures), and selectively combine pages from multiple PDF documents into one by simple copy & paste.
- bootload 10y ago
  "Personally I find that Apple Preview has always been good enough for these tasks." OSS is a good choice because not every developer works on a Mac and with binary apps. You can hack quite a few quick/dirty tools to deal with repetitive tasks. Having said that Apple Preview is a pretty useful tool.
- pschastain 10y ago
  Except Preview 8 (post-Mavericks) sucks. Annotations of any kind always appear in the center of the page and have to be manually moved into position, it doesn't easily recognize selections, combined documents don't always retain changes, I could go on. I have a Mavericks VM just for Preview 7. [edit] grammar
revelation 10y ago
The issue with taking arbitrary user uploads and piping them directly into a program that happily accepts and interprets arbitrary data is security. They claim support for over 200 formats, some of which surely have exciting scripting functionality that no one ever uses: http://www.imagemagick.org/script/formats.php http://www.imagemagick.org/script/formats.php And there have been recent code execution vulnerability reports: https://imagetragick.com/ https://imagetragick.com/ Now libpng (e.g.) has issues as well but if at all possible I would try to restrict the input format and process only with software for the specific format.
amelius 10y ago
> HN would probably mostly be interested in it for server-side applications This image processing system would be very useful to have on the client. (Why can't we still use arbitrary stuff on the client that was written for the server?)
- Spivak 10y ago
  You can if you're shipping a native app. But if you're targeting the web you're limited by tools written in JS or what you can transcribe to JS. asm.js and WebAssembly could very well change this in a few years.
  - bobajeff 10y ago
    To further clarify SIMD.js (along WebAssembly's SIMD.js hooks) will change this. Right now you can still port GraphicsMagick to emscripten you'd just have to accept a performance hit on the parts that rely on SIMD.
deleted 10y ago
[deleted]

by patio11 10y ago

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.
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.

pavlov 10y ago

Personally I find that Apple Preview has always been good enough for these tasks. It can also do a surprising amount of PDF editing: for example, you can draw annotations on pages (for highlights and signatures), and selectively combine pages from multiple PDF documents into one by simple copy & paste.

bootload 10y ago
"Personally I find that Apple Preview has always been good enough for these tasks." OSS is a good choice because not every developer works on a Mac and with binary apps. You can hack quite a few quick/dirty tools to deal with repetitive tasks. Having said that Apple Preview is a pretty useful tool.
pschastain 10y ago
Except Preview 8 (post-Mavericks) sucks. Annotations of any kind always appear in the center of the page and have to be manually moved into position, it doesn't easily recognize selections, combined documents don't always retain changes, I could go on. I have a Mavericks VM just for Preview 7. [edit] grammar

revelation 10y ago

The issue with taking arbitrary user uploads and piping them directly into a program that happily accepts and interprets arbitrary data is security. They claim support for over 200 formats, some of which surely have exciting scripting functionality that no one ever uses: http://www.imagemagick.org/script/formats.php http://www.imagemagick.org/script/formats.php And there have been recent code execution vulnerability reports: https://imagetragick.com/ https://imagetragick.com/ Now libpng (e.g.) has issues as well but if at all possible I would try to restrict the input format and process only with software for the specific format.

amelius 10y ago

> HN would probably mostly be interested in it for server-side applications This image processing system would be very useful to have on the client. (Why can't we still use arbitrary stuff on the client that was written for the server?)

Spivak 10y ago
You can if you're shipping a native app. But if you're targeting the web you're limited by tools written in JS or what you can transcribe to JS. asm.js and WebAssembly could very well change this in a few years.
- bobajeff 10y ago
  To further clarify SIMD.js (along WebAssembly's SIMD.js hooks) will change this. Right now you can still port GraphicsMagick to emscripten you'd just have to accept a performance hit on the parts that rely on SIMD.

deleted 10y ago

[deleted]