Commit Graph

6 Commits

Author SHA1 Message Date
Even Rouault
371ad2658c
Make defer strile offset/bytecount loading available at runtime
... 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.
2019-05-10 14:46:45 +02:00
Thomas Bernard
933575f505
add a test for fax2tiff tool 2019-03-22 10:06:01 +01:00
Even Rouault
4af64003c8
Fix libtiff 4.0.8 regression when reading LZW-compressed strips with scanline API
Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2800
2018-08-07 11:54:27 +02:00
Even Rouault
abc862b594 * test/tiffcp-lzw-compat.sh, test/images/quad-lzw-compat.tiff: new files
to test old-style LZW decompression
* test/common.sh, Makefile.am, CMakeList.txt: updated with above
2017-07-11 09:20:31 +00:00
Even Rouault
f2a3b02040 * .travis.yml, build/travis-ci: new files from
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.
2017-06-08 20:46:10 +00:00
Bob Friesenhahn
5b90af247e * CMakeLists.txt: Add CMake patchset by Roger Leigh as posted to
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'.
2015-06-25 02:27:58 +00:00