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
deprecated arguments still work, but are not shown in help, nor are they
checked for "have-been-set"
you can tag required and optional args as deprecated ... obviously if
you deprecate a required argument you must replace it with a new
argument or scripts will break
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
- shrink down to a 1x1 pixel tile, even for very long and thin images
- round image size up on shrink
- write a .dzi file with the pyramid params
- default tile size and overlap now matches the openslide writer
thanks to Benjamin Gilbert for pointing out the errors
we used to have minor version numbers in the pkg-confiog files, eg:
pkg-config vips-7.28 --cflags
The idea was to make working with multiple installed versions (something
I do a lot at least) easier. But it was also annoying and made upgrading
harder for downstream packages. And the benefits were very marginal.
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 vips base class was causing global balance to leak a bit
vips8 adds extra refs back though the pipeline -- this means that when
you make _local objects, they MUST be local to output. If they are local
to input, you'll get a ref cycle and a leak
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.
the vips7 loaders were a thin layer over the new VipsForeign system
however! VipsForeign does various "useful" things, like open via disc,
and this resulted in stuff like
vips im_jpeg2vips huge.jpg x.v
decompressing to a temp file before copying to x.v
im_jpeg2vips() and friends now call the low-level loaders directly and
avoid the extra mechanisms in VipsForeign
"nip2 huge.jpg" was loading twice as well, for the same reason
