Alien-FreeImage
view release on metacpan or search on metacpan
src/Source/LibTIFF4/tif_open.c view on Meta::CPAN
* use of memory-mapped files and strip chopping when
* a file is opened read-only.
*/
tif->tif_flags = FILLORDER_MSB2LSB;
if (m == O_RDONLY )
tif->tif_flags |= TIFF_MAPPED;
#ifdef STRIPCHOP_DEFAULT
if (m == O_RDONLY || m == O_RDWR)
tif->tif_flags |= STRIPCHOP_DEFAULT;
#endif
/*
* Process library-specific flags in the open mode string.
* The following flags may be used to control intrinsic library
* behaviour that may or may not be desirable (usually for
* compatibility with some application that claims to support
* TIFF but only supports some braindead idea of what the
* vendor thinks TIFF is):
*
* 'l' use little-endian byte order for creating a file
* 'b' use big-endian byte order for creating a file
* 'L' read/write information using LSB2MSB bit order
* 'B' read/write information using MSB2LSB bit order
* 'H' read/write information using host bit order
* 'M' enable use of memory-mapped files when supported
* 'm' disable use of memory-mapped files
* 'C' enable strip chopping support when reading
* 'c' disable strip chopping support
* 'h' read TIFF header only, do not load the first IFD
* '4' ClassicTIFF for creating a file (default)
* '8' BigTIFF for creating a file
*
* The use of the 'l' and 'b' flags is strongly discouraged.
* These flags are provided solely because numerous vendors,
* typically on the PC, do not correctly support TIFF; they
* only support the Intel little-endian byte order. This
* support is not configured by default because it supports
* the violation of the TIFF spec that says that readers *MUST*
* support both byte orders. It is strongly recommended that
* you not use this feature except to deal with busted apps
* that write invalid TIFF. And even in those cases you should
* bang on the vendors to fix their software.
*
* The 'L', 'B', and 'H' flags are intended for applications
* that can optimize operations on data by using a particular
* bit order. By default the library returns data in MSB2LSB
* bit order for compatibiltiy with older versions of this
* library. Returning data in the bit order of the native cpu
* makes the most sense but also requires applications to check
* the value of the FillOrder tag; something they probably do
* not do right now.
*
* The 'M' and 'm' flags are provided because some virtual memory
* systems exhibit poor behaviour when large images are mapped.
* These options permit clients to control the use of memory-mapped
* files on a per-file basis.
*
* The 'C' and 'c' flags are provided because the library support
* for chopping up large strips into multiple smaller strips is not
* application-transparent and as such can cause problems. The 'c'
* option permits applications that only want to look at the tags,
* for example, to get the unadulterated TIFF tag information.
*/
for (cp = mode; *cp; cp++)
switch (*cp) {
case 'b':
#ifndef WORDS_BIGENDIAN
if (m&O_CREAT)
tif->tif_flags |= TIFF_SWAB;
#endif
break;
case 'l':
#ifdef WORDS_BIGENDIAN
if ((m&O_CREAT))
tif->tif_flags |= TIFF_SWAB;
#endif
break;
case 'B':
tif->tif_flags = (tif->tif_flags &~ TIFF_FILLORDER) |
FILLORDER_MSB2LSB;
break;
case 'L':
tif->tif_flags = (tif->tif_flags &~ TIFF_FILLORDER) |
FILLORDER_LSB2MSB;
break;
case 'H':
tif->tif_flags = (tif->tif_flags &~ TIFF_FILLORDER) |
HOST_FILLORDER;
break;
case 'M':
if (m == O_RDONLY)
tif->tif_flags |= TIFF_MAPPED;
break;
case 'm':
if (m == O_RDONLY)
tif->tif_flags &= ~TIFF_MAPPED;
break;
case 'C':
if (m == O_RDONLY)
tif->tif_flags |= TIFF_STRIPCHOP;
break;
case 'c':
if (m == O_RDONLY)
tif->tif_flags &= ~TIFF_STRIPCHOP;
break;
case 'h':
tif->tif_flags |= TIFF_HEADERONLY;
break;
case '8':
if (m&O_CREAT)
tif->tif_flags |= TIFF_BIGTIFF;
break;
}
/*
* Read in TIFF header.
*/
if ((m & O_TRUNC) ||
!ReadOK(tif, &tif->tif_header, sizeof (TIFFHeaderClassic))) {
if (tif->tif_mode == O_RDONLY) {
TIFFErrorExt(tif->tif_clientdata, name,
( run in 0.357 second using v1.01-cache-2.11-cpan-d0baa829c65 )