To make a distinction that "transparent" is not a valid ImageMagick
color, we suggest using a Symbol, and reserve strings only for valid
ImageMagick color.
We also fix a typo where we used :color option instead of :background.
We also remove the "TRANSPARENT" constant, as any RGB values with the
alpha of 0 will be transparent, so this is not one and only transparent
color, it's just transparent white.
ImageMagick does have options that apply specifically to loading and
saving images. The saver options could already be defined via the
chainable API, but the loader options couldn't, because they need to be
specified before the input image in the shell command.
While we're here, we also recommend specifying the "jpeg:size" hint when
generating multiple thumbnails to avoid loading the whole image into
memory, which resulted in about 2x speedup in my benchmarks.
When it comes to colors, libvips works a bit differently than
ImageMagick. With ImageMagick if you specify the alpha channel in the
background color, the alpha channel will be automatically added to the
image if it supports it (e.g. when output format is PNG).
However, in libvips you need to add the alpha channel manually if you're
converting from a format that doesn't have it (such as JPEG). Since we
don't know what will be the output format at the time of processing, we
don't know whether we should add the additional alpha channel or not,
so we make it opt-in.
When an alpha channel is added, any colors now need to be specified as
an array of 4 numbers, specifying an array with 3 numbers will raise an
exception. The vips_gravity() will by default use a background color
with all bits set to 0, which will be black when there is no alpha
channel, and transparent when there is an alpha channel.
Previous version didn't work with PNGs that have an alpha channel,
because we were always specifying background color with 3 numbers, and
PNGs with alpha channel needs 4 numbers or it will raise an exception.
Because of this reason we also needed to remove the Vips::Color module,
as it contained only RGB colors which wouldn't work with RGBA images. We
could theoretically retrieve the number of bands, and add an alpha
channel of 255 in this case, but I don't really understand what bands
are and maybe some images may have 5 or 2 bands, so I would prefer to
make as few assumptions as possible.
Different Vips savers accept different options. At the moment the
developer needs to know exactly which formats accept provided saver
options, because when these options are forwarded to a saver which
doesn't accept this options an error is raised.
Instead of the developer having to know which output formats accept the
:Q option and which don't, they can now specify this option and it will
be forwarded only to savers that accept it, while for others it will be
ignored.
See #17 for the discussion.
Janko Marohnić