core/vil: core/vil/file_formats/vil

    Modifications
     3 Oct 2001 Peter Vanroose - Implemented get_property and set_property
     5 Jan 2002 Ian Scott      - Converted to vil
     9 Dec 2003 Peter Vanroose - Added support for 1-bit pixel (bitmapped) images
     21 Dec 2005 J.L. Mundy - Substantial rewrite to handle a more
         complete tiff 6.0 standard. Files with tiles can now be read and
         written. Only tiled images are considered blocked, i.e. not strips.
         Block dimensions must be a multiple of 16, for compatibility with
         compression schemes. Tiff files with separate color bands are not handled
     24 Mar 2007 J.L. Mundy - added smart pointer on TIFF handle to support
         multiple resources from a single tiff file; required for pyramid
     KNOWN BUG - 24bit samples for both nplanes = 1 and nplanes = 3

Go to the source code of this file.


Classes
class	vil_tiff_file_format
	Loader for tiff files. More...
struct	tif_ref_cnt
struct	tif_smart_ptr
class	vil_tiff_image
	Generic image interface for image TIFF image files (could have multiple images). More...
struct	tiff_pyramid_level
	--------- Representation of Pyramid Images by multi-image TIFF ------- More...
class	vil_tiff_pyramid_resource
	Pyramid resource built on the multi-image capability of the TIFF format. More...
Functions
template<class T>
T	tiff_get_bits (const T *in_val, unsigned i0, unsigned ni)
	This function does a lot of work for.
template<class T>
T *	tiff_byte_align_data (T in_data, unsigned num_samples, unsigned in_bits_per_sample, T out_data)
	This function will byte align the data in in_data and store the result in out_data.
template<>
bool *	tiff_byte_align_data< bool > (bool in_data, unsigned num_samples, unsigned in_bits_per_sample, bool out_data)

Function Documentation

template<class T>
T* tiff_byte_align_data	(	T *	in_data,
		unsigned	num_samples,
		unsigned	in_bits_per_sample,
		T *	out_data
	)

This function will byte align the data in in_data and store the result in out_data.

For example, let's say that you had in_data is of type unsigned char and contains the following data: 110010111001111010000110. In other words: in_data[0] = 203 (11001011) in_data[1] = 158 (10011110) in_data[2] = 134 (10000110) Let's further say you called this function like this: byte_align_data( in_data, 8, 3, out_data ). Then, when the function finished, out_data would look like this: out_data[0] = 6 (00000110) out_data[1] = 2 (00000010) out_data[2] = 7 (00000111) out_data[3] = 1 (00000001) out_data[4] = 7 (00000111) out_data[5] = 2 (00000010) out_data[6] = 0 (00000000) out_data[7] = 6 (00000110)

Basically, what the function did was group the bitstream into groups of three and then store all of the values into out_data. It had to zero pad all the values (on the MSB side) to get them into out_data. That's why out_data is bigger.

This function works with other unsigned types of data too. For example, let's say in_data was of type unsigned int and contained the following bits: 0100110010111000 0111101100000000 1111000011110000 (note that this bitstream is shown in big endian notation, that will not be the case if you are on a little endian machine -- this is just for illustration) in other words: in_data[0] = 19640 (0100110010111000) [shown in big endian for illustrative purposes only] in_data[1] = 31488 (0111101100000000) [shown in big endian for illustrative purposes only] in_data[2] = 61680 (1111000011110000) [shown in big endian for illustrative purposes only] Let's further say, you called this function like this byte_align_data( in_data, 4, 12, out_data ). Then out_data would be aligned along two byte (sixteen bit) boundaries and would look like this: out_data[0] = 1227 (0000010011001011) [shown in big endian for illustrative purposes only] out_data[1] = 2171 (0000100001111011) [shown in big endian for illustrative purposes only] out_data[2] = 15 (0000000000001111) [shown in big endian for illustrative purposes only] out_data[3] = 240 (0000000011110000) [shown in big endian for illustrative purposes only]

Because of the fact that this function uses bit shifting operators, and the behavior of the vcl_right shift operator is implementation specific when applied to a negative number, you should probably only use this function on unsigned data.

Parameters:

	in_data,:	The input data. It must be at least (num_samples*in_bits_per_sample) bytes long. The values should have the endianness of your platform.
	num_samples,:	The number of actual samples in in_data.
	in_bits_per_sample,:	The bits per sample in in_data
	out_data,:	I'll store the output data here. It must be at least (num_samples*sizeof(T)) bytes long The values will have the endianness of your platform.

Note that inBitsPerSampe must not be >= sizeof(T). If they were to be equal, then this function would have nothing to do (in_data is already byte aligned). If in_bits_per_sample were less than sizeof(T), then each element of out_data would be too small to store the corresponding elements in in_data.

Note that there is a specialization for the bool case which just casts it to an 8 bit quantity then calls this same function. This is because the logic in get_bits<> doesn't work for the bool case.

Definition at line 526 of file vil_tiff.h.

template<>
bool* tiff_byte_align_data< bool >	(	bool *	in_data,
		unsigned	num_samples,
		unsigned	in_bits_per_sample,
		bool *	out_data
	)

template<class T>
T tiff_get_bits	(	const T *	in_val,
		unsigned	i0,
		unsigned	ni
	)

This function does a lot of work for.

See also:: byte_align_data(). It will strip one value of ni bits and return it as a value of type T (with zero padding on the MSBs). Both io and ni are lengths (in bits - not bytes).

Parameters:

	i0,:	Offset (in bits - not bytes) from in_val[0]. This will be the start of the bits extracted from in_val.
	ni,:	number of bits (starting from i0) that will be extracted from in_val.

Definition at line 428 of file vil_tiff.h.

vil_tiff.h File Reference

Detailed Description

Classes

Functions

Function Documentation