The vips driver program was parsing options in a single pass. This
failed if an option came in two parts, for example:
vips --plugin x.plg list
the argument to --plug would be picked up as the action for "vips",
since actions were selected before option parsing
Now we parse in two passes: the first pass picks up options for vips
itself and for the libvips library, then we select the action, then we
parse again, including any options created by the action
We were not capturing warnings from libtiff until we used libtiff
ourselves. Other libraries whcih we call, such as ImageMagick, could use
libtiff and generate an uncaptured warning.
On Windows these warnings each produced a popup.
you now get something like:
$ vips tiffsave k2.jpg x.tif --compression poop
tiffsave: enum 'VipsForeignTiffCompression' has no member 'poop', should be one of: none, jpeg, deflate, packbits, ccittfax4, lzw
previously, jpeg save always used pixels/inch and jpeg load converted to
vips pixels/mm
now on jpg load the image's res unit is recorded in
VIPS_META_RESOLUTION_UNIT, and on jpg save the res unit is set from
VIPS_META_RESOLUTION_UNIT (or defaults to inches).
you can now copy a cm-preferring tiff to a jpg and the unit is preserved
we were turning on ycbcr for all jpeg tiffs and relying on the jpeg
compressor to only use it when possible ... now just turn on ycbcr for
8-bit RGB images
vips_sequential() no longer bans all non-seq access, it just bans
rewinding --- if you ask for something some way ahead, it reads and
throws away pixels
this means VipsExtract and VipsInsert can now be seq: they will read and
throw away any stuff they don't need
the new sequential mode readers for tiff/jpg/png were not working well
from the vips7 command-line: they either decompressed twice, or handed
over a sequential mode image
it should now work as well as it did pre-seq.
cli operations turn on seq mode automatically when they can
vips_operation_get_flags() added: lets you attach a set of flags to an
operation
flags for now are "nocache" (replacing the old nocache system) and "seqential"
if vips_object_set_argument_from_string() from string sees "seq" flag on the
object for which it is setting the arg, it enables sequential mode
all operations which can run sequentially have been tagged
the operation printer knows about flags and can display them
lock around the operation cache and the upstrea/downstream link system
so vips works when used from many threads: you can now create an image
in one thread and process it in another
on end of an image loop, send a "minimise" signal down the pipeline
tilecache listens for this signal on its output and drops the cache
helps reduce ruby memuse
