summaryrefslogtreecommitdiff
path: root/libtiff/tif_dir.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'fix_484_TIFFDirectory_32_64_bit' into 'master'Even Rouault2023-05-071-4/+4
|\ | | | | | | | | | | | | Fix 484 TIFFDirectory td_fieldsset uses unsigned long which can be 32 or 64 bits. Closes #484 See merge request libtiff/libtiff!471
| * Fix 484 TIFFDirectory td_fieldsset uses unsigned long which can be 32 or 64 ↵Su_Laus2023-02-081-4/+4
| | | | | | | | | | | | bits. Closes #484
* | Even faster TIFFSetDirectory() using IFD list.Su Laus2023-03-261-0/+4
|/
* TIFFCurrentDirectory(), TIFFNumberOfDirectories(), TIFFSetDirectory(), ↵Even Rouault2022-12-121-2/+2
| | | | TIFFUnlinkDirectory(): use tdir_t that is now a uint32_t, and raise limit of IFDs to 1048576
* Reformatting in libtiff/ using 'pre-commit run'pre-commit run by Even Rouault2022-12-081-215/+240
|
* Remove vim/emacs formatting footersEven Rouault2022-12-081-10/+0
|
* Merge branch 'InkNames_NumberOfInks_handling_revised' into 'master'Even Rouault2022-10-121-0/+2
|\ | | | | | | | | | | | | Revised handling of TIFFTAG_INKNAMES and related TIFFTAG_NUMBEROFINKS value (fixes #149, #150, #152, #168, #250, #269, #398 and #456) Closes #474, #463, #387, #456, #398, #269, #250, #168, #152, #150 et #149 See merge request libtiff/libtiff!385
| * Revised handling of TIFFTAG_INKNAMES and related TIFFTAG_NUMBEROFINKS valueSu_Laus2022-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to solve the buffer overflow issues related to TIFFTAG_INKNAMES and related TIFFTAG_NUMBEROFINKS value, a revised handling of those tags within LibTiff is proposed: Behaviour for writing: `NumberOfInks` MUST fit to the number of inks in the `InkNames` string. `NumberOfInks` is automatically set when `InkNames` is set. If `NumberOfInks` is different to the number of inks within `InkNames` string, that will be corrected and a warning is issued. If `NumberOfInks` is not equal to samplesperpixel only a warning will be issued. Behaviour for reading: When reading `InkNames` from a TIFF file, the `NumberOfInks` will be set automatically to the number of inks in `InkNames` string. If `NumberOfInks` is different to the number of inks within `InkNames` string, that will be corrected and a warning is issued. If `NumberOfInks` is not equal to samplesperpixel only a warning will be issued. This allows the safe use of the NumberOfInks value to read out the InkNames without buffer overflow This MR will close the following issues: #149, #150, #152, #168 (to be checked), #250, #269, #398 and #456. It also fixes the old bug at http://bugzilla.maptools.org/show_bug.cgi?id=2599, for which the limitation of `NumberOfInks = SPP` was introduced, which is in my opinion not necessary and does not solve the general issue.
* | Improved IFD-Loop Handling (fixes #455)Su Laus2022-10-061-0/+2
|/ | | | | | | | | | | | | | | | | | | | | | IFD infinite looping was not fixed by MR 20 (see #455). An improved IFD loop handling is proposed. Basic approach: - The order in the entire chain must be checked, and not only whether an offset has already been read once. - To do this, pairs of directory number and offset are stored and checked. - The offset of a directory number can change. - TIFFAdvanceDirectory() must also perform an IFD loop check. - TIFFCheckDirOffset() is replaced by _TIFFCheckDirNumberAndOffset(). Rules for the check: - If an offset is already in the list, it must have the same IFD number. Otherwise it is an IDF loop. - If the offset is not in the list and the IFD number is greater than there are list entries, a new list entry is added. - Otherwise, the offset of the IFD number is updated. Reference is also made to old bugzilla bug 2772 and MR 20, which did not solve the general issue. This MR closes #455
* extra flag for anonymous (unknown) tags (fixes #8)Su_Laus2022-04-061-2/+2
|
* Use standard C99 integer typesRoger Leigh2021-01-211-44/+44
|
* EXIF 2.32 and GPS tags and functionality upgraded.Su_Laus2020-03-071-0/+2
| | | | | | | | | | | | | | - Existing EXIF field definition of tags is upgraded to EXIF version 2.3.2 - EXIF-GPS structure, tags and access functions are added as special CustomDirectory (like it was done for EXIF). - Test program custom_dir_EXIF_231.c added to test writing/reading of EXID IFD and GPS IFD tags and to highlight some quirks of IFD-handling and peculiarities of reading/writing the different data types. - Reading error for FileSource and SceneType tags corrected. - EXIF_GPS_upgrade rebased onto c8c5309b765ef4ff097d2aaffbdb8f403db8967d (Merge branch 'Rational2DoublePrecision_correction' into 'master') and adapted: - tif_dirinfo.c: All rational tags set to TIFF_SETGET_FLOAT but only the GPSTAG_ tags set to TIFF_SETGET_DOUBLE. - custom_dir_EXIF_231.c: Editorials amended and gcc warnigs fixed. - CMakeLists.txt: add_test(NAME "custom_dir_EXIF_231" COMMAND "custom_dir_EXIF_231") added.
* Reading of Tiff tags with ID = 0 (like GPSVERSIONID) corrected.Su Laus2019-08-041-0/+1
| | | | | | | | | | | | | | | | | | | | | IGNORE placeholder in tif_dirread.c is now replaced by a field dir_ignore in the TIFFDirEntry structure Currently, in tif_dirread.c a special IGNORE value for the tif tags is defined in order to flag status preventing already processed tags from further processing. This irrational behaviour prevents reading of custom tags with id code 0 - like tag GPSVERSIONID from EXIF 2.31 definition. An additional field 'tdir_ignore' is now added to the TIFFDirEntry structure and code is changed to allow tags with id code 0 to be read correctly. This change was already proposed as pending improvement in tif_dirread.c around line 32. Reference is also made to: - Discussion in https://gitlab.com/libtiff/libtiff/merge_requests/39 - http://bugzilla.maptools.org/show_bug.cgi?id=2540 Comments and indention adapted. Preparation to rebase onto master
* Add TIFFDeferStrileArrayWriting() and TIFFForceStrileArrayWriting()Even Rouault2019-05-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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.
* Make defer strile offset/bytecount loading available at runtimeEven Rouault2019-05-101-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... 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.
* Add includes to headers to allow them to stand alone.Kurt Schwehr2018-10-241-0/+4
| | | | | This allows compilers that can do header stand alone header parsing to process libtiff.
* Remove all $Id and $Headers comments with CVS versionsEven Rouault2017-11-301-2/+0
|
* * libtiff/tif_dirinfo.c, tif_dirread.c: add _TIFFCheckFieldIsValidForCodec(),Even Rouault2017-06-011-1/+2
| | | | | | | | | | | | | | | | | | | and use it in TIFFReadDirectory() so as to ignore fields whose tag is a codec-specified tag but this codec is not enabled. This avoids TIFFGetField() to behave differently depending on whether the codec is enabled or not, and thus can avoid stack based buffer overflows in a number of TIFF utilities such as tiffsplit, tiffcmp, thumbnail, etc. Patch derived from 0063-Handle-properly-CODEC-specific-tags.patch (http://bugzilla.maptools.org/show_bug.cgi?id=2580) by Raphaël Hertzog. Fixes: http://bugzilla.maptools.org/show_bug.cgi?id=2580 http://bugzilla.maptools.org/show_bug.cgi?id=2693 http://bugzilla.maptools.org/show_bug.cgi?id=2625 (CVE-2016-10095) http://bugzilla.maptools.org/show_bug.cgi?id=2564 (CVE-2015-7554) http://bugzilla.maptools.org/show_bug.cgi?id=2561 (CVE-2016-5318) http://bugzilla.maptools.org/show_bug.cgi?id=2499 (CVE-2014-8128) http://bugzilla.maptools.org/show_bug.cgi?id=2441 http://bugzilla.maptools.org/show_bug.cgi?id=2433
* implement optional support for deferred strip/tile offset/size loadingFrank Warmerdam2011-02-181-1/+29
|
* Added support for TIFFTAG_SMINSAMPLEVALUE and TIFFTAG_SMAXSAMPLEVALUE to haveOlivier Paquet2011-01-241-2/+3
| | | | | | | different values for each sample. Presents the min/max of all samples by default for compatibility. TIFFSetField/TIFFGetField can be made to handle those tags as arrays by changing the new TIFFTAG_PERSAMPLE pseudo tag. http://www.asmail.be/msg0055458208.html
* * libtiff/tif_aux.c (_TIFFCheckRealloc): Improve error message soBob Friesenhahn2010-03-101-1/+8
| | | | | that it is clearly a memory allocation error message, and also includes the size of the allocation request.
* Return to handling TIFFTAG_REFERENCEBLACKWHITE as a field in the TIFFFrank Warmerdam2009-11-301-1/+3
| | | | | directory instead of as a custom(generic) field to avoid a potential reentrancy problem (#2125)
* Transition to the new-style tag extending scheme completed.Andrey Kiselev2007-07-121-30/+26
|
* Remove mis-placed comma.Bob Friesenhahn2007-07-121-2/+2
|
* Even more work to improve tag extending scheme. tif_fieldinfo member in TIFFAndrey Kiselev2007-07-101-18/+69
| | | | | structure renamed into tif_fields to be consistent with the new function names.
* More work on new tag extending scheme. Use the new scheme everywhere.Andrey Kiselev2007-07-091-9/+2
|
* Rename TIFFMergeField() function into TIFFMergeFields().Andrey Kiselev2007-07-091-2/+2
|
* TIFFFIeldInfo structure replaced with TIFFField structure. TIFFFieldInfoAndrey Kiselev2007-07-081-5/+38
| | | | retained for the backward compatibility.
* TIFFTagValue structure moved from the public tiffio.h to private tif_dir.h.Andrey Kiselev2007-07-041-1/+8
|
* BigTIFF upgrade: misc little things, indentation and some compiler warnings ↵Joris Van Damme2007-06-261-18/+18
| | | | workarounds
* BigTIFF upgrade: mostly TIFFFieldInfo related stuff, anticipating future tag ↵Joris Van Damme2007-06-231-5/+4
| | | | handling plans
* BigTIFF upgrade: misc little things, mostly indentation and unimportant stuffJoris Van Damme2007-06-211-11/+1
|
* BigTIFF upgrade: type restoration - not so messy anymoreJoris Van Damme2007-06-121-5/+5
|
* BigTIFF upgrade in tif_dirwrite.c - still temp messJoris Van Damme2007-06-081-2/+2
|
* BigTIFF upgrade in tif_dirwrite.c - still temp messJoris Van Damme2007-06-071-2/+2
|
* BigTIFF upgrade in tif_dirwrite.c - still temp messJoris Van Damme2007-06-061-38/+38
|
* Finally fix bug http://bugzilla.remotesensing.org/show_bug.cgi?id=1274 byAndrey Kiselev2007-04-071-2/+2
| | | | | | | introducing _TIFFMergeFieldInfo() returning integer error status instead of void in case of problems with field merging (e.g., if the field with such a tag already registered). TIFFMergeFieldInfo() in public API remains void. Use _TIFFMergeFieldInfo() everywhere and check returned value.
* BigTIFF upgrade in progress - widespread temp mess - does not compile nowJoris Van Damme2007-04-041-13/+12
|
* BigTIFF upgrade in progress - widespread temp mess - does not compile nowJoris Van Damme2007-03-311-1/+1
|
* BigTIFF upgrade in progress - widespread temp mess - does not compile nowJoris Van Damme2007-03-311-4/+4
|
* BigTIFF upgrade in progressJoris Van Damme2007-03-221-4/+4
|
* BigTIFF upgrade in progressJoris Van Damme2007-03-171-4/+4
|
* Added a comments about future development directions.Andrey Kiselev2006-10-121-2/+2
|
* new ojpeg supportJoris Van Damme2006-04-041-36/+39
|
* tiffFieldInfo and exifFieldInfo arrays definitions moved back toAndrey Kiselev2005-12-261-477/+4
| | | | | tif_dirinfo.c; added _TIFFGetFieldInfo() and _TIFFGetExifFieldInfo() private functions to retrieve FieldInfo arrays.
* Make InkSet, NumberOfInks, DotRange and StoNits tags custom.Andrey Kiselev2005-12-241-20/+13
|
* Make WhitePoint tag custom.Andrey Kiselev2005-12-231-17/+2
|
* More EXIF tags added.Andrey Kiselev2005-12-231-6/+54
|
* Make RichTIFFIPTC, Photoshop and ICCProfile tags custom.Andrey Kiselev2005-12-211-16/+4
|
* Added more EXIF tags.Andrey Kiselev2005-12-121-2/+44
|
View Lorry Controller Status