Meeting results

[John Ivens <jivens@hindmost.LPL.Arizona.EDU>]

//Pixels have these attributes and are stored together in this geometry:
//This class renamed to Pixel_Description

class Pixel_Description {
        unsigned short ID;      Specific ID number 
        char code;              Code marker (CVS identifier)
        DataType data_type;     IEEE_INTEGER, etc.
        byte_orders byte_order; How bits and bytes are ordered and
stored
        int pixel_bits;         Number of bits in this pixel
        float pixel_bytes;      Number of bytes this pixel fits into
	int axes;               The number of axes in the data
	int axis_order[axes];	The order in which the axes are stored
        Axis_Vector axis[axes]; An array of axis information
};

// These types are more generic
enum byte_orders { ICL_BIG_ENDIAN, ICL_LITTLE_ENDIAN, etc. };
enum DataType { IEEE_INTEGER, IEEE_FLOATING_POINT, IEEE_DOUBLE, etc. };

class Axis_Vector {
        int size;               How many pixels are in this dimension
        Direction direction;    Either positive or negative
};

enum Direction { '+', '-' };

// The order is relative to an assumed order of axes, namely 
// (0,0,0) at the uppermost left corner of the "cube"
// +x going "across"
// +y going "down"
// +z going "back"

// As an example
// Sample=X,3samples across; Band=Z,size=2 bands in; Line=Y,size4 lines
down
axis_order[0] = 0;
axis_order[1] = 2;
axis_order[2] = 1;
// Now we know that the third axis (Z) is the second fastest
axis[0].size = 2; 		// 0-based
axis[0].direction = '+';
axis[1].size = 1; 		// 0-based
axis[1].direction = '+';
axis[2].size = 3; 		// 0-based
axis[2].direction = '+';
//This allows us to step through the arrays in the original dimensions


//Images have this kind of structure:

//Image-+
//      +->Pixel_Data-+
//      |             +-->Pixel_Description----->Axis_Vector
//      |             +-->Pixel_Buffer
//      |
//      +->Attributes-+
//      |             +-->Name
//      |             +-->Value
//      |
//      +->Description
//      |
//      +->Driver-----+
//                    +-->File_Info
//                    +-->Private


//The Image object will be passed around between the APP, ICL and
DRIVER.
//Note that we are potentially passing a C++ object to a C driver.
//In this case there will need to be struct munging.  UGH!
//The Value of an Attribute will be an object describing an Attribute.  
//There needs to be more discussion on this point.

//The Pixel_Buffer will hold the actual array of pixel values
//The Pixel_Description entries are derived from the Attributes

//Description is some as-yet-to-be-discussed user image description

//Driver contains the File_Info in some way that can be queried
//Private is what only Mr. and Ms. Driver needs to know.  No peeking!!

//The mini-drivers are statically compiled and linked.  
//The DRIVER is dynamically linked.

//What we don't know yet:
//	How do we subset an image?
//	How do we write an image to a file?
//	How do we write an image to memory?
//	In general, what is the chain of events for changing an image?
//	For example, we change the dimensions of the image by subsetting
//	the image.  Now, how do the appropriate attributes get changed, 
//	and at what level(s) do they get changed, and when?