On Wednesday, October 30, 2013 6:12:59 PM UTC+1, James Bardin wrote:
Nice work.

There's a number of bindings floating around currently (another cgo
version here, https://github.com/gographics/imagick), and we have our own
we use internally for GraphicsMagick.

Did you by chance compare the gographics library?
Thanks! I wasn't aware of any other bindings for IM nor GM. We've been
using this internally since August 2012 and there were no public bindings
at that time, so we wrote our own. From a quick look at go graphics, it
seems they're wrapping the MagickWand library, while we're wrapping
MagickCore, so it seems both packages are intended for different use cases.

As an aside, the developer on the gographics/imagick library had mentioned
writing a Go version of the {Image|Graphics}Magick api. I think that would
be great if some of the image library users got together to start work on a
GoMagick library.
I think that would be a terrible waste of time and the developer is
severely underestimating the effort required. IM or GM are big projects,
around 500K lines for IM and I guess GM is in the same ballpark.
Furthermore, they rely on other C libraries for some other tasks, like
decoding some formats. Porting everything from C to Go would require many
many hours and, probably, you'll end up with a slower implementation than
using cgo to call to the C libraries. The only benefit would be able to run
on environments when using cgo/unsafe is not allowed (like GAE), but I
personally have zero interest in those.

A first step that I think would be interesting, is cgo bindings to the
native image encoders, where you could `import _ "image/jpeg_cgo"` and get
faster encode/decode performance with the stdlib.
We already have written (and thrown away) decoders for png, jpeg and gif,
with both encoding and decoding support. We initially wrote them to get
better decoding/encoding support (image/gif didn't support encoding at the
time, and all image/* packages failed to decode 20-30% of our sample set),
but we found that even with libpng/libjpeg/libgif based decoders, Go's
image package still sucked. Want to resize an image? Write your own
algorithm! Need to work with animated GIFs? Not supported! If you need to
do anything barely advanced with images, just forget about the packages in
the standard library. You'll eventually hit a wall and will have to rewrite
all your image handling code using a real image library.

On Wednesday, October 30, 2013 12:29:21 PM UTC-4, Alberto García Hierro

We've just released our bindings for ImageMagick/GraphicsMagic. The
former is used by default, but the latter can be enabled using the gm build
tag. We debated for a few weeks which backend should be default, and we
ended up going for IM because it's better at handling optimized GIFs (GM
can't decode heavily optimized GIF images), although GM is noticeably
faster. Depending on your use case, you might be better off using the GM

In our performance tests, we've found that GM is around 120x faster than
the image related modules in the standard library when it comes to
decoding/resizing/cropping/encoding images.

Source code is available at https://github.com/rainycape/magick

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 12 | next ›
Discussion Overview
groupgolang-nuts @
postedOct 30, '13 at 4:29p
activeFeb 13, '16 at 4:14a



site design / logo © 2022 Grokbase