The Exif standard defines the following data types for comments. Usage is dependent of your development platform. To see the usage, refer to the code example for your platform.
|ASCII||Character string terminated with a NULL character. The length includes the NULL character.|
|BYTE||Array of bytes (unsigned 8-bit values)|
|SBYTE||Array of signed bytes (signed 8-bit values)|
|UNDEFINED||The data type is determined by the field. (The count is number of bytes).|
|SHORT||Unsigned 16-bit integer|
|SSHORT||Signed 16-bit integer|
|LONG||Unsigned 32-bit integer|
|SLONG||Signed 32-bit integer|
|RATIONAL||An array of two unsigned long integers that express a fraction. The first value is the numerator, and the second is the denominator.|
|SRATIONAL||An array of two signed long integers that express a fraction. The first value is the numerator, and the second is the denominator.|
|FLOAT||32-bit floating point value|
|DOUBLE||64-bit floading point value|
The byte length of a comment is based on the data type. For example, an SRATIONAL with a length of 3 is an array of 6 long integers.
The values are represented by the corresponding TAG_XXX values from ltfil.h. For example, ASCII is TAG_ASCII (2), BYTE is TAG_BYTE (1), etc.
When a comment that requires an array is set, the array can be zero-based (where the first element has an index of 0) or one-based (where the first element has an index of 1). When you get a comment that is an array, it will always be zero-based.
UNDEFINED is an array of bytes, which might require reinterpreting and compensating for the byte order. For example, if there are two values (a SHORT followed by a LONG), then you would have 6 UNDEFINED bytes: first two bytes representing a SHORT and the next four representing a LONG. The byte order is the byte order of the original file. LEADTOOLS will not process the data to account for the byte order because it does not know the format of the data.
Medical Web Viewer .NET
.NET, Java, Android, and iOS/macOS Assemblies
C API/C++ Class Libraries