| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instanciate compute ntrips as TIFFhowmany_32(td->td_imagelength, rowsperstrip),
instead of a logic based on the total size of data. Which is faulty is
the total size of data is not sufficient to fill the whole image, and thus
results in reading outside of the StripByCounts/StripOffsets arrays when
using TIFFReadScanline().
Reported by Agostino Sarubbo.
Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2608.
* libtiff/tif_strip.c: revert the change in TIFFNumberOfStrips() done
for http://bugzilla.maptools.org/show_bug.cgi?id=2587 / CVE-2016-9273 since
the above change is a better fix that makes it unnecessary.
|
|
|
|
|
|
|
| |
value when it is non-zero, instead of recomputing it. This is needed in
TIFF_STRIPCHOP mode where td_nstrips is modified. Fixes a read outsize of
array in tiffsplit (or other utilities using TIFFNumberOfStrips()).
Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2587
|
|
|
|
| |
"Division or modulo by zero".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TIFF_UINT64_FORMAT appropriately for MinGW32.
* tools/tiffdump.c (ReadDirectory): MinGW32 needs to use WIN32
printf conventions for 64-bit types because it uses the WIN32 CRT.
* libtiff/{tif_dumpmode.c,tif_luv.c,tif_lzw.c,tif_print.c,
tif_read.c,tif_strip.c,tif_thunder.c}: MinGW32 needs to use WIN32
printf conventions for 64-bit types because it uses the WIN32 CRT.
* tools/tiff2pdf.c (t2p_write_pdf_string): Fix printf syntax not
understood by WIN32 CRT.
|
| |
|
|
|
|
|
| |
that it is clearly a memory allocation error message, and also
includes the size of the allocation request.
|
|
|
|
| |
jpeg compressed ycbcr images.
|
|
|
|
| |
pixel or subsampling ratios (#1927).
|
| |
|
|
|
|
| |
restoration of tif_dirwrite.c
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
case of integer overflow now. Properly handle this case in TIFFReadDirectory()
(patches from Dmitry V. Levin).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|