4 ms·

This looks nice! I especially appreciate the example images with simple code. This looks like it could be used to re-implement a lot ImageMagick fairly easily

This looks nice! I especially appreciate the example images with simple code. This looks like it could be used to re-implement a lot ImageMagick fairly easily. I love ImageMagick (well, except for hijacking really generic command names like 'convert' and 'identify'), but re-implementing those features in a memory managed language like Go is a real security bonus for servers processing images from untrusted sources. See ImageTragick.

pjmlp 7y ago
I have used Java2D and System.Drawing for similar purposes.
solarkraft 7y ago
On one hand yes, on the other how much performance do you lose to the memory management? Maybe Rust would be a better choice for maximal performance?
- LambdaComplex 7y ago
  Last time I looked, the `image` crate was the defacto standard for doing image manipulation in Rust, and in my opinion its API is/was pretty bad. (Had several different types for "an image," which made things annoying, and I recall hitting unreachable!() in a public function once).
- jerf 7y ago
  Memory management for a one-and-done image conversion isn't much of an issue. The program will pretty much allocate, run a few very fast GCs since almost all memory usage is in a handful of big arrays (some people seem to have this idea that all GCs are multi-millisecond ordeals, which isn't the case), and then at program termination just throw everything away. A program like this could get away with an allocator implementation that allocated normally but whose "free" is a no-op [1]. What would slow something like this down is not using the relevant assembly code to accelerate working with these images. A very quick glance at the convolution package, chosen on the grounds that if anything is ASM it probably is, shows that this really is "pure Go", in the sense that it doesn't use Go's ASM support. The compiler will not optimize that to speak of, certainly there's no autovectorization, so it's going to be significantly slower than an optimized program that does make correct use of vectorized operations. Though, in theory, this can be cleaned up over time. Go does have the support built-in for fixing that in a reasonably nice way, as long as you don't mind that it has its own assembler dialect. [1]: Not 100% related, but close enough, the part towards the end: http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941 http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over...
- pjmlp 7y ago
  Less that the anti-GC crowd thinks, specially when the right algorithms get used, one does not allocate like crazy, and just like in Rust pays attention to where data gets allocated and how.
- shanemhansen 7y ago
  I can give you a real answer. If you use go's image and color interfaces then boxing can stress the allocator if you process pixel by pixel. But assuming you represent and process your image as a packed slice of rgba or something, the gc wont be in your way at all. Source: led team that built production go image resizing and conversion services at walmartlabs.
pram 7y ago
Another major benefit would be to dump having an ImageMagick dependency, and just deploy with a native Go library. Right now I have to use convert on some files (PNG) because I've experienced issues with the native Go libs.

pjmlp 7y ago

I have used Java2D and System.Drawing for similar purposes.

solarkraft 7y ago

On one hand yes, on the other how much performance do you lose to the memory management? Maybe Rust would be a better choice for maximal performance?

LambdaComplex 7y ago
Last time I looked, the `image` crate was the defacto standard for doing image manipulation in Rust, and in my opinion its API is/was pretty bad. (Had several different types for "an image," which made things annoying, and I recall hitting unreachable!() in a public function once).
jerf 7y ago
Memory management for a one-and-done image conversion isn't much of an issue. The program will pretty much allocate, run a few very fast GCs since almost all memory usage is in a handful of big arrays (some people seem to have this idea that all GCs are multi-millisecond ordeals, which isn't the case), and then at program termination just throw everything away. A program like this could get away with an allocator implementation that allocated normally but whose "free" is a no-op [1]. What would slow something like this down is not using the relevant assembly code to accelerate working with these images. A very quick glance at the convolution package, chosen on the grounds that if anything is ASM it probably is, shows that this really is "pure Go", in the sense that it doesn't use Go's ASM support. The compiler will not optimize that to speak of, certainly there's no autovectorization, so it's going to be significantly slower than an optimized program that does make correct use of vectorized operations. Though, in theory, this can be cleaned up over time. Go does have the support built-in for fixing that in a reasonably nice way, as long as you don't mind that it has its own assembler dialect. [1]: Not 100% related, but close enough, the part towards the end: http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941 http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over...
pjmlp 7y ago
Less that the anti-GC crowd thinks, specially when the right algorithms get used, one does not allocate like crazy, and just like in Rust pays attention to where data gets allocated and how.
shanemhansen 7y ago
I can give you a real answer. If you use go's image and color interfaces then boxing can stress the allocator if you process pixel by pixel. But assuming you represent and process your image as a packed slice of rgba or something, the gc wont be in your way at all. Source: led team that built production go image resizing and conversion services at walmartlabs.

pram 7y ago

Another major benefit would be to dump having an ImageMagick dependency, and just deploy with a native Go library. Right now I have to use convert on some files (PNG) because I've experienced issues with the native Go libs.