Use GLib's i18n support instead of copying and pasting that
logic into its own header. This deprecates the vips/intl.h
header in favour of glib/gi18n.h.
By default, a dynamically loadable module is built for *magick (i.e.
`--with-magick=module`) when:
* ImageMagick or GraphicsMagick is found;
* GModule is supported (`gmodule_supported` pkg-config variable).
This can be overridden on the command line with:
* `--without-magick` - to disable *magick usage;
* `--with-magick[=yes]` - to restore the previous behavior;
* `--disable-modules` - to disable the build of dynamic modules.
Prevents a zero-length buffer from crashing GetImageMagick
It looks like the fix for magick7 in #1642 is also now required
for magick6 as the assertion appears to have been backported.
We used to Ping files to see if IM would load them, but this can be
extremely slow for file formats like ARW.
Instead, use GetImageMagick() ... it just checks the magic number.
Some magick coders (eg. ICO) don't sniff the filetype from the data, so
when you try to load from a string, imagemagick is unable to pick the
right decode path.
Add a @format option so callers can hint the filetype.
see https://github.com/jcupitt/pyvips/issues/39
various cosmetic changes:
- pngsave_buffer now uses Write, not WriteBuf, same change for
radsave_buffer
- move C wrappers out to class defs from foreign.c
- use g_free() not vips_free() for buffer free from low-level savers
- fix var names in some comments
- various style changes for radiance.c
works, but is no faster, how odd
john@kiwi:~/pics$ time vips magickload nipguide.pdf[40] x.tif
real 0m0.244s
user 0m0.212s
sys 0m0.040s
$ time vips magickload nipguide.pdf x.tif --page 40
real 0m7.035s
user 0m6.900s
sys 0m0.152s
both give same result
ruby gobject-introspection is quite fussy about needing a lot of const
declarations ... these changes help vips_image_matrix_from_array()
appear in Ruby
Kleis Auke Wolthuizen
Lovell Fuller
John Cupitt
Dirk Lemstra
Alistair Thomas
Maurus Cuelenaere
Benjamin Gilbert