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?
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?
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.
https://groups.google.com/d/msg/golang-nuts/6qVpOGyDuHI/kpjrtX39aHgJ
I think that would be a terrible waste of time and the developer iswriting 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.
https://groups.google.com/d/msg/golang-nuts/6qVpOGyDuHI/kpjrtX39aHgJ
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,native image encoders, where you could `import _ "image/jpeg_cgo"` and get
faster encode/decode performance with the stdlib.
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
wrote:
Hi,
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
backend.
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
Regards,
Alberto
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
backend.
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
Regards,
Alberto
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.