Unfortunately, custom rational tags (TIFF_RATIONAL with field_bit=FIELD_CUSTOM) are defined as TIFF_SETGET_DOUBLE
but for the reading interface and LibTiff internally they are stored ALLWAYS as floating point SINGLE precision.
Double precision custom rational tags are not supported by LibTiff.
For the GPS tags in WGS84 a higher accuracy / precision is needed.
Therefore, this upgrade is made, keeping the old interface for the already defined tags and allowing a double precision definition,
as well as calculating rationals with higher accuracy / precision.
This higher accuracy can be used for newly defined tags like that in EXIF/GPS.
Refer also to the very old Bugzilla issue 2542 (#69)
A test file rational_precision2double.c is added, which shows prevention of the old interface to the already defined custom rational tags
with the standard library as well as with the upgraded library.
Also TIFFTAG_XRESOLUTION, TIFFTAG_YRESOLUTION, TIFFTAG_XPOSITION, TIFFTAG_YPOSITION amended from TIFF_SETGET_DOUBLE to TIFF_SETGET_FLOAT and testcase inserted in rational_precision2double.c
in configure/CMakeList.txt :
- TIFF_INT8_T/TIFF_UINT8_T is signed/unsigned char
sizeof(char)==1 in C standard
- TIFF_INT16_T/TIFF_UINT16_T is signed/unsigned short
sizeof(short)>=2 in C standard
- TIFF_INT32_T/TIFF_UINT32_T is defined so its sizeof() is 4
- TIFF_INT64_T/TIFF_UINT64_T is defined so its sizeof() is 8
- TIFF_SIZE_T is defined so it has same sizeof() than size_t
- TIFF_SSIZE_T is defined so it has same sizeof() than unsigned char *
Those advanced writing functions must be used in a particular sequence
to make their intended effect. Their aim is to control when/where
the [Strip/Tile][Offsets/ByteCounts] arrays are written into the file.
The purpose of this is to generate 'cloud-optimized geotiff' files where
the first KB of the file only contain the IFD entries without the potentially
large strile arrays. Those are written afterwards.
The typical sequence of calls is:
TIFFOpen()
[ TIFFCreateDirectory(tif) ]
Set fields with calls to TIFFSetField(tif, ...)
TIFFDeferStrileArrayWriting(tif)
TIFFWriteCheck(tif, ...)
TIFFWriteDirectory(tif)
... potentially create other directories and come back to the above directory
TIFFForceStrileArrayWriting(tif): emit the arrays at the end of file
See test/defer_strile_writing.c for a practical example.
This function replaces the use of TIFFReadEncodedStrip()/TIFFReadEncodedTile()
when the user can provide the buffer for the input data, for example when
he wants to avoid libtiff to read the strile offset/count values from the
[Strip|Tile][Offsets/ByteCounts] array.
... and add per-strile offset/bytecount loading capabilities.
Part of this commit makes the behaviour that was previously met when
libtiff was compiled with -DDEFER_STRILE_LOAD available for default builds
when specifying the new 'D' (Deferred) TIFFOpen() flag. In that mode, the [Tile/Strip][ByteCounts/Offsets]
arrays are only loaded when first accessed. This can speed-up the opening
of files stored on the network when just metadata retrieval is needed.
This mode has been used for years by the GDAL library when compiled with
its embeded libtiff copy.
To avoid potential out-of-tree code (typically codecs) that would use
the td_stripbytecount and td_stripoffset array inconditionnaly assuming they
have been loaded, those have been suffixed with _p (for protected). The
use of the new functions mentionned below is then recommended.
Another addition of this commit is the capability of loading only the
values of the offset/bytecount of the strile of interest instead of the
whole array. This is enabled with the new 'O' (Ondemand) flag of TIFFOpen()
(which implies 'D'). That behaviour has also been used by GDAL, which hacked
into the td_stripoffset/td_stripbytecount arrays directly. The new code
added in the _TIFFFetchStrileValue() and _TIFFPartialReadStripArray() internal
functions is mostly a port of what was in GDAL GTiff driver previously.
Related to that, the public TIFFGetStrileOffset[WithErr]() and TIFFGetStrileByteCount[WithErr]()
functions have been added to API. They are of particular interest when
using sparse files (with offset == bytecount == 0) and you want to detect
if a strile is present or not without decompressing the data, or updating
an existing sparse file.
They will also be used to enable a future enhancement where client code can entirely
skip bytecount loading in some situtations
A new test/defer_strile_loading.c test has been added to test the above
capabilities.
0001-ci-Add-Travis-support-for-Linux-builds-with-Autoconf.patch by
Roger Leigh (sent to mailing list on 2017-06-08)
This patch adds support for the Travis-CI service.
* .appveyor.yml: new file from
0002-ci-Add-AppVeyor-support.patch by Roger Leigh (sent to mailing
list on 2017-06-08)
This patch adds a .appveyor.yml file to the top-level. This allows
one to opt in to having a branch built on Windows with Cygwin,
MinGW and MSVC automatically when a branch is pushed to GitHub,
GitLab, BitBucket or any other supported git hosting service.
* CMakeLists.txt, test/CMakeLists.txt, test/TiffTestCommon.cmake: apply
patch 0001-cmake-Improve-Cygwin-and-MingGW-test-support.patch from Roger
Leigh (sent to mailing list on 2017-06-08)
This patch makes the CMake build system support running the tests
with MinGW or Cygwin.
ras2tiff, sgi2tiff, sgisv, and ycbcr are completely removed from
the distribution. The libtiff tools rgb2ycbcr and thumbnail are
only built in the build tree for testing. Old files are put in
new 'archive' subdirectory of the source repository, but not in
distribution archives. These changes are made in order to lessen
the maintenance burden.
Roger Leigh (via tiff mailing list on 2015-09-01) to fix issue
with BSD make and to make use of cmake in 'distcheck' target
conditional on if cmake is available.
Roger Leigh (via tiff mailing list on 2015-08-31.
CMake reads all version information directly from configure.ac to
avoid duplication of values. This basically greps over the file
for the LIBTIFF_* variables, then translates them to the form
needed for cmake. This includes the release version and libtool
shared library version information.
Make shared/static library building configurable. Currently it
always builds shared libraries, with static libs having a _static
suffix (copying zlib, but it means it's got a non-standard name).
CMake has a -DBUILD_SHARED_LIBS=ON|OFF option to select one or the
other, which is now used instead. There's now a single "tiff"
target to build either shared or static as required, and all the
tests and tools are linked with this. Note: the Windows tests fail
when linked with a static libtiff (says: libtiff.dll not found).
Not really a regression since this was not tested up to this
point, and it's likely the unit tests haven't (ever?) been run on
Windows with a static libtiff, so there's some additional
portability issue here to address. Works fine on UNIX systems,
and fine on Windows with the default to build a DLL.
Add a missing file which wasn't being distributed, causing unit
tests to fail. Note that "find . -name '*.cmake'" lists all the
CMake files which need distributing in addition to all the
CMakeLists.txt files (which now are distributed).
libtiff mailing list on Mon, 22 Jun 2015 21:21:01 +0100. Several
corrections to ensure that the autotools build still works were
added by me. I have not yet tested the build using 'cmake' or
MSVC with 'nmake'.
add-on library.
* test/Makefile.am (JPEG_DEPENDENT_CHECK_PROG): raw_decode
requires JPEG support to compile. Use Automake conditional to
only include it when JPEG support is available.
