Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Truevision TGA.
Nothing was collected or created yet.
Truevision TGA
View on Wikipediafrom Wikipedia
 | This article needs additional citations for verification. (March 2014) |
| Truevision TGA | |
|---|---|
| Filename extensions |
.tga, .icb, .vda, .vst |
| Internet media type |
image/x-targa[1] image/x-tga |
| Type code | 'TPIC' |
| Uniform Type Identifier (UTI) | com.truevision.tga-image |
| Developed by | Truevision |
| Type of format | Raster image file |
Truevision TGA, often referred to as TARGA, is a raster graphics file format created by Truevision (now part of Avid Technology). It was the native format of TARGA and VISTA boards, which were the first graphic cards for IBM PC compatibles to support high color or true color display. This family of graphic cards was intended for professional computer image synthesis; the usual resolutions of TGA image files match those of the NTSC and PAL video formats.[2]
TARGA is an acronym for Truevision Advanced Raster Graphics Adapter; TGA is an initialism for Truevision Graphics Adapter.
TGA files commonly have the extension ".tga" on MS-DOS, Windows, and macOS (older Macintosh systems use the "TPIC" type code). The format itself permits any pixel bit depth up to 255, of which up to 15 bits can be dedicated to an alpha channel;[3] however, the only bit depths supported in practice were 8, 15, 16, 24, and 32, where the 16- and 32-bit formats used 1 and 8 bits respectively for the alpha channel. Color data can be color-mapped, or in direct color or truecolor format. Image data may be stored raw, or optionally, a lossless RLE compression similar to PackBits can be employed. This type of compression performs poorly for typical photographic images, but works acceptably well for simpler images, such as icons, cartoons and line drawings.
History
[edit]The TGA file format was originally defined and specified by AT&T EPICenter with feedback from Island Graphics Inc in 1984. AT&T EPICenter was an internal spin-off of AT&T created to market new technologies AT&T had developed for color frame buffers. What later became Truevision was the result of a leveraged employee buyout from AT&T in 1987.
EPICenter's first two cards, the VDA (video display adapter) and ICB (image capture board), used the first incarnations of the TGA file format. The file extensions ".vda" and ".icb" implied information about the board specific data contained.
It was later determined by Alan Wlasuk (then head of EPICenter), Brad Pillow (EPICenter) and Steven Dompier (Island's president) that a more codified file format was needed. The file format was created and implemented by Brad Pillow (EPICenter) and Bryan Hunt (EPICenter) and was developed in response to this need for a less board specific file format. A very simple extension was made to what was already in use, and contained information on width, height, pixel depth, an associated color map and image origin. A label field (up to 255 characters) was also included in the initial spec, but was rarely used.
At the time, another technically superior file format called TIFF also appeared, but its use for true color images was very limited as the implementation and sharing of files between applications supporting the TIFF specification was rather difficult and involved. The TGA file format's simpler nature and portability between platforms is the main reason for its widespread adoption and its continued success in a wide variety of applications worldwide to this day.
Initially the TGA file format was used in the ICB-PAINT and TARGA-PAINT programs (what later became known as TIPS) and for several projects in online real estate browsing and still-frame video teleconferencing.
The current version (2.0) includes several enhancements such as "postage stamps" (better known as thumbnails), an alpha channel, gamma value, and textual metadata, and was authored by Truevision Inc.'s Shawn Steiner with direction from Kevin Friedly and David Spoelstra in 1989.
At the time of its launching, it represented the state of the art in digital image processing. Even today, though its maximum color depth is not well suited for high-end pre-press, intensive image processing systems, TGA is still used extensively throughout the animation and video industry because its primary intended outputs are standard TV screens, not color printed pages.[4]
Uncompressed 24-bit TGA images are relatively simple compared to several other prominent 24-bit storage formats: A 24-bit TGA contains only an 18-byte header followed by the image data as packed RGB data. In contrast, BMP requires padding rows to 4-byte boundaries, while TIFF and PNG are metadata containers that do not place the image data or attributes at a fixed location within the file.
32-bit TGA images contain an alpha channel, or key signal, and are often used in character generator programs such as Avid Deko.
Technical details
[edit]All values are little-endian; field and subfield numbers are per Version 2.0 of the specification.
Version 2.0 added the extension area and footer. The developer area exists to store application-specific information.
Header
[edit]| Field no. | Length | Field name | Description |
|---|---|---|---|
| 1 | 1 byte | ID length | Length of the image ID field |
| 2 | 1 byte | Color map type | Whether a color map is included |
| 3 | 1 byte | Image type | Compression and color types |
| 4 | 5 bytes | Color map specification | Describes the color map |
| 5 | 10 bytes | Image specification | Image dimensions and format |
Image ID length (field 1)
0–255 The number of bytes that the image ID field consists of. The image ID field can contain any information, but it is common for it to contain the date and time the image was created or a serial number.
As of version 2.0 of the TGA spec, the date and time the image was created is catered for in the extension area.
Color map type (field 2)
has the value:
- 0 if image file contains no color map
- 1 if present
- 2–127 reserved by Truevision
- 128–255 available for developer use
Image type (field 3)
is enumerated in the lower three bits, with the fourth bit as a flag for RLE. Some possible values are:
- 0 no image data is present
- 1 uncompressed color-mapped image
- 2 uncompressed true-color image
- 3 uncompressed grayscale image
- 9 run-length encoded color-mapped image
- 10 run-length encoded true-color image
- 11 run-length encoded grayscale image
- 32 huffman-delta-run-length encoded color-mapped image
- 33 huffman-delta-run-length-4-pass-quadtree-type process encoded color-mapped image
Image type 1 and 9: Depending on the Pixel Depth value, image data representation is an 8, 15, or 16 bit index into a color map that defines the color of the pixel. Image type 2 and 10: The image data is a direct representation of the pixel color. For a Pixel Depth of 15 and 16 bit, each pixel is stored with 5 bits per color. If the pixel depth is 16 bits, the topmost bit is reserved for transparency. For a pixel depth of 24 bits, each pixel is stored with 8 bits per color. A 32-bit pixel depth defines an additional 8-bit alpha channel. Image type 3 and 11: The image data is a direct representation of grayscale data. The pixel depth is 8 bits for images of this type.
Color map specification (field 4)
has three subfields:
- First entry index (2 bytes): index of first color map entry that is included in the file
- Color map length (2 bytes): number of entries of the color map that are included in the file
- Color map entry size (1 byte): number of bits per color map entry
In case that not the entire color map is actually used by the image, a non-zero first entry index allows to store only a required part of the color map in the file.
Image specification (field 5)
has six subfields:
- X-origin (2 bytes): absolute coordinate of lower-left corner for displays where origin is at the lower left
- Y-origin (2 bytes): as for X-origin
- Image width (2 bytes): width in pixels
- Image height (2 bytes): height in pixels
- Pixel depth (1 byte): bits per pixel
- Image descriptor (1 byte): bits 3–0 give the alpha channel depth, bits 5–4 give pixel ordering, bits 7-6 data storage interleaving[3]
Image descriptor:
- Bit 3-0 give the alpha channel depth
- Bit 4 of the image descriptor byte indicates right-to-left pixel ordering if set.
- Bit 5 indicates an ordering of top-to-bottom. Otherwise, pixels are stored in bottom-to-top, left-to-right order.
- Bit 7-6 of the image descriptor byte indicate the data storage interleaving mode.
Data storage interleaving mode:
- 0 none
- 1 two-way (even/odd) interleaving
- 2 four-way interleaving
- 3 eight-way interleaving/reserved
Image and color map data
[edit]| Field no. | Length | Field | Description |
|---|---|---|---|
| 6 | From image ID length field | Image ID | Optional field containing identifying information |
| 7 | From color map specification field | Color map data | Look-up table containing color map data |
| 8 | From image specification field | Image data | Stored according to the image descriptor |
Developer area (optional)
[edit]Version 1.0 of the TGA specification was very basic, and many developers had a need to store more information, and so opted to add on extra sections to their files, specific to their application only.[citation needed]
In Version 2.0 of the specification, these application-specific enhancements/extras are supported by the developer area. Only the offset and size of the developer area are relevant to the spec, and developers are free to add whatever they want in the area.
If a TGA decoder cannot interpret the information in the developer area, it will generally ignore it, since it is assumed to have been created by a different application. It is recommended that developers build logic into their applications to determine whether the data in the developer area is compatible with the application; one step towards this is to check the software ID in the file footer.
Extension area (optional)
[edit]| Field no. | Length | Field | Description |
|---|---|---|---|
| 10 | 2 bytes | Extension size | Size in bytes of the extension area, always 495 |
| 11 | 41 bytes | Author name | Name of the author. If not used, bytes should be set to NULL (\0) or spaces |
| 12 | 324 bytes | Author comment | A comment, organized as four lines, each consisting of 80 characters plus a NULL |
| 13 | 12 bytes | Date/time stamp | Date and time at which the image was created |
| 14 | 41 bytes | Job ID | |
| 15 | 6 bytes | Job time | Hours, minutes and seconds spent creating the file (for billing, etc.) |
| 16 | 41 bytes | Software ID | The application that created the file. |
| 17 | 3 bytes | Software version | |
| 18 | 4 bytes | Key color | |
| 19 | 4 bytes | Pixel aspect ratio | |
| 20 | 4 bytes | Gamma value | |
| 21 | 4 bytes | Color correction offset | Number of bytes from the beginning of the file to the color correction table if present |
| 22 | 4 bytes | Postage stamp offset | Number of bytes from the beginning of the file to the postage stamp image if present |
| 23 | 4 bytes | Scan line offset | Number of bytes from the beginning of the file to the scan lines table if present |
| 24 | 1 byte | Attributes type | Specifies the alpha channel |
File footer (optional)
[edit]If a TGA file contains a footer, it is likely to be a TGA version 2 file. The footer is the final 26 bytes of the file, of which the last 18 are constant.
| Field no. | Length | Field | Description |
|---|---|---|---|
| 28 | 4 bytes | Extension offset | Offset in bytes from the beginning of the file |
| 29 | 4 bytes | Developer area offset | Offset in bytes from the beginning of the file |
| 30 | 16 bytes | Signature | Contains "TRUEVISION-XFILE" |
| 31 | 1 byte | Contains "." | |
| 32 | 1 byte | Contains NUL |
Specification discrepancies
[edit]The older version of the TGA file format specification taken from the Appendix C of the Truevision Technical Guide states that run-length encoded (RLE) packets may cross scan lines: "For the run length packet, the header is followed by a single color value, which is assumed to be repeated the number of times specified in the header. The packet may cross scan lines (begin on one line and end on the next)".
However, page 24 of the TGA v2.0 specification states the exact opposite: "Run-length Packets should never encode pixels from more than one scan line. Even if the end of one scan line and the beginning of the next contain pixels of the same value, the two should be encoded as separate packets. In other words, Run-length Packets should not wrap from one line to another".
Consequently TGA readers need to be able to handle RLE data packets that cross scan lines since this was part of the original specification. However, when saving (creating) TGA files it will be necessary to limit RLE data packets to scanline boundaries in order to be compliant with the newer v2.0 TGA specification.
References
[edit]- ^ .tga MIME type not registered at IANA
- ^ James D. Murray; William vanRyper (April 1996). Encyclopedia of Graphics File Formats, Second Edition. O'Reilly. ISBN 1-56592-161-5. Retrieved 2014-03-07.
- ^ a b "Truevision TGAª — FILE FORMAT SPECIFICATION — Version 2.0" (PDF).
- ^ "Truevision TGA, version 2.0". Digital Preservation. Library of Congress. 2005-02-24. Retrieved 2021-06-08.
External links
[edit]- TGA specification – previous version of the file format taken from the Truevision Technical Guide
- TrueVision TGA 2.0 conformance suite – examples
- TGA format specification - includes extended image type/descriptor flags
| Raster |
|
|---|---|
| Raw | |
| Vector | |
| Compound | |
| Metadata |
|
Truevision TGA
View on Grokipediafrom Grokipedia
The Truevision TGA (TARGA), often abbreviated as TGA, is a raster graphics file format developed by Truevision, Inc. in 1984 for storing individual images, initially designed for use with their early truecolor (24-bit RGB) graphic cards on MS-DOS systems and extended to version 2.0 in 1989.[1] It supports a range of bit depths from 8 to 32 bits per pixel, including indexed color, direct RGB, and RGBA modes with an alpha channel for transparency, enabling applications like image compositing.[1] The format accommodates both uncompressed and run-length encoded (RLE) compression for efficient storage, while version 2.0 additions include pixel aspect ratios, color correction tables, thumbnails, and basic metadata such as author names and dates.[2][1]
Originally native to Truevision's TARGA and VISTA graphics boards, TGA gained prominence in professional graphics, video production, and early computer imaging due to its support for high-fidelity color reproduction without proprietary licensing restrictions.[3] Its flexibility, including 32-bit true color (24-bit RGB plus 8-bit alpha) and compatibility with extensions like .vda, .icb, and .vst, made it suitable for both still images and video sequences in tools such as Autodesk 3ds Max.[3] Despite competition from formats like TIFF and PNG, TGA remains relevant in specialized fields, particularly video game development, where it is favored for its non-proprietary nature and direct support in engines like Valve's Source, often serving as a base for compiled texture files.[4]
TGA's sustainability is bolstered by its publicly available specification and broad software support, though it lacks advanced self-documentation features compared to modern formats.[2] Common file identifiers include the .tga extension and a header starting with ID length byte 0-255, followed by fixed fields for image type, width, height, and pixel depth.[2] While uncompressed TGA files preserve exact pixel data, RLE compression reduces size for repetitive content, though it can introduce minor compatibility issues in some game pipelines.[4]
Key fields within the header provide critical details for rendering and processing. The Pixel Depth field determines the color resolution and channel configuration, with common values including 8 bits for grayscale images, 24 bits for truecolor RGB without alpha, and 32 bits for RGB with an 8-bit alpha channel.[2] The Image Descriptor byte further refines data layout by specifying the position of alpha bits (if any) and the scanline orientation, which indicates whether pixel rows are stored from bottom to top or top to bottom, and left to right or right to left, affecting how software displays the image without flipping. Bits 7-6 must be set to zero.[2]
In file parsing, the header dictates the structure and interpretation of all following elements, such as the presence and size of a color map or the expected format of pixel data, ensuring compatibility across different TGA implementations without dependence on optional extensions.[2] The Image Type field may also signal the potential for an optional extension area in advanced variants.[2]
This table illustrates representative uncompressed formats, emphasizing contiguous per-pixel storage for efficient decoding.[11]
The extension area's optional components include the postage stamp (thumbnail) image, which provides a low-resolution preview (typically 128x128 pixels or smaller, stored as raw 8-bit data), and the scan line table, which supports non-contiguous or irregular image storage by listing byte offsets for each scan line. The alpha channel attributes type field here integrates with the image descriptor in the header to define transparency handling. The extension area's location is specified by a 4-byte offset in the file footer (0 if absent).[7][2]
The file footer is a fixed 26-byte terminator located at the end of the file, serving as a version identifier and pointer to optional areas for reliable parsing. It consists of an 18-byte ASCII signature "TRUEVISION-XFILE." (followed by a NULL byte), a 4-byte little-endian offset to the extension area (0 if none), and a 4-byte little-endian offset to the developer directory (0 if none). This structure ensures that parsers can detect version 2.0+ files and safely skip or process the optional areas without misinterpreting earlier TGA versions.[7][2]
In practice, these optional areas are appended directly after the image data, with their presence determined by non-zero offsets in the footer; parsers must always check the footer's signature and offsets to avoid errors when reading files that may lack them, promoting robust handling across software implementations. While often underutilized, they enable metadata-rich workflows in professional graphics applications.[2][1]
History and Development
Origins
Truevision originated as AT&T EPICenter, an internal spin-off of AT&T established in 1984 to commercialize the company's advancements in color frame buffer technologies, with a primary emphasis on developing graphics hardware for IBM PC-compatible systems.[5] This initiative addressed the growing demand for high-resolution color displays in early personal computing environments, where standard VGA capabilities were limited to 16 colors. The Truevision TGA (Targa) file format was developed that same year as a raster image standard specifically tailored for Truevision's pioneering TARGA and VISTA video boards, enabling the capture, storage, and display of high-color and true-color images in MS-DOS-based applications.[1] These boards represented the first graphics adapters for IBM PC compatibles to support 24-bit true color, facilitating professional video digitization and manipulation tasks that were previously constrained by monochrome or low-color systems.[6] The initial specification, released in 1984, focused on efficient output from video board hardware and supported uncompressed data for color-intensive raster images.[7] In 1987, following AT&T's decision to dissolve the EPICenter division, a leveraged employee buyout led to the formation of the independent Truevision Inc., which continued to develop the TGA format, enhancing its versatility for emerging graphics workflows.[5] From its inception, the TGA format was designed as non-proprietary, distributed without licensing fees to encourage widespread adoption across hardware and software developers in the graphics industry.[8]Evolution of Versions
The Truevision TGA file format was first introduced in version 1.0 in 1984 as a basic raster format designed for storing individual images on early videographics hardware, such as Truevision's TARGA boards for IBM-compatible PCs.[9] This initial version supported uncompressed data and was limited to up to 8-bit color mapping for indexed colors, alongside direct RGB representations at bit depths of 8, 16, 24, or 32 bits per pixel.[9] It provided essential functionality for truecolor imaging in professional graphics applications but lacked advanced metadata or extensibility features.[9] In 1989, Truevision released version 2.0 of the TGA specification, which expanded the format's capabilities while maintaining backward compatibility with version 1.0 files.[1] Key additions included an optional extension area for storing thumbnails, pixel aspect ratio information, color correction tables, and developer-specific metadata, as well as support for run-length encoded (RLE) compression, enabling more sophisticated image handling in software.[1] A formal technical manual for version 2.0 was published in January 1991 (manual version 2.2), documenting these enhancements and standardizing the format's structure with a new footer containing the "TRUEVISION-XFILE." signature to identify compliant files.[10] Following the 1991 manual, no major revisions to the TGA specification occurred, though public documentation provided minor clarifications on versions 1.0 and 2.0 to aid preservation and implementation.[9][1] Ongoing compatibility efforts addressed support for bit depths up to 32 bits, ensuring the format's viability in evolving hardware environments without altering core specifications.[1] However, variations in header field interpretations across implementations have arisen, such as inconsistencies in handling the color map length field, which specifies the number of color map entries and can lead to interoperability issues when partial maps are used.[8] These discrepancies often stem from third-party extensions or differing adherence to the original technical guide.[8]File Format Structure
Header
The Truevision TGA file format begins with a fixed 18-byte header that encapsulates essential metadata about the image, including its dimensions, color specifications, and data organization.[2] This header is mandatory for all TGA files and serves as the primary reference for parsers to interpret the subsequent data sections.[2] The header structure consists of the following fields in sequence:| Offset | Field Name | Size (bytes) | Description |
|---|---|---|---|
| 0 | ID Length | 1 | Number of bytes in the optional Image ID field (0-255; 0 indicates no ID field). |
| 1 | Color Map Type | 1 | Specifies whether a color map (palette) is present (0 = none, 1 = palette included; other values reserved). |
| 2 | Image Type | 1 | Defines the type of image data (0 = no image data, 1-9 = various uncompressed or compressed formats including indexed, truecolor, and grayscale). |
| 3 | Color Map Specification | 5 | First Entry Index (2 bytes): Starting index of the color map. Color Map Length (2 bytes): Number of color map entries. Color Map Entry Size (1 byte): Bits per color map entry (e.g., 15, 16, 24, or 32). |
| 8 | Image Specification | 10 | X-Origin (2 bytes): Horizontal offset of the image's lower-left corner. Y-Origin (2 bytes): Vertical offset of the image's lower-left corner. Image Width (2 bytes): Width of the image in pixels. Image Height (2 bytes): Height of the image in pixels. Pixel Depth (1 byte): Bits per pixel (e.g., 8 for grayscale, 16 for RGB565, 24 for RGB, 32 for RGBA). Image Descriptor (1 byte): Encodes additional attributes (bits 3-0: number of alpha/attribute bits per pixel; bit 4: horizontal orientation (1 = left-to-right, 0 = right-to-left); bit 5: vertical orientation (1 = top-to-bottom, 0 = bottom-to-top); bits 7-6: reserved as zero). |
Image and Color Map Data
The image and color map data sections form the core payload of a Truevision TGA file, immediately following the header and any image identification field. If the color map type field in the header (byte 2) is set to 1, indicating a color-mapped image, a color map follows, consisting of up to 256 palette entries as specified by the color map length (bytes 6-7 of the header). Each entry's size is defined by the color map entry size field (byte 8), typically 24 bits for RGB (8 bits each for red, green, and blue components) or 32 bits including an alpha channel, with entries stored in little-endian order starting from the first entry index (bytes 3-4).[2] The color map data occupies a variable length calculated as the number of entries multiplied by the entry size in bytes, providing indexed color representation for images such as 8-bit palettized formats.[11] The image data section, which always follows the color map (if present), contains the raster pixel values in a contiguous block for the specified width and height from the header (bytes 9-12 and 13-16, respectively). Pixels are stored in row-major order, traversing rows from the image origin defined by the image descriptor byte (byte 17): bit 5 determines vertical orientation (0 for bottom-to-top, starting at the lower-left; 1 for top-to-bottom, starting at the upper-left), while bit 4 controls horizontal direction (1 for left-to-right; 0 for right-to-left).[2] For uncompressed images (types 1 for color-mapped, 2 for true-color, or 3 for grayscale), the data is raw and non-interleaved, with all channels for a pixel stored contiguously rather than in separate planes.[2][11] Supported pixel depths, indicated by byte 16 of the header, include 8 bits for grayscale (monochrome, no color map) or palettized images, 24 bits for RGB true-color (8 bits per channel: blue, green, red in that order), and 32 bits for RGBA (adding an 8-bit alpha channel for transparency).[2] Other depths like 15 or 16 bits are possible for packed RGB formats (e.g., 5-5-5 or 5-6-5 bit allocations with an attribute bit), but 8-bit grayscale, 24-bit RGB, and 32-bit RGBA represent the most common configurations for direct color storage.[11] The attribute bits per pixel (bits 3-0 of byte 17) specify any additional data, such as alpha utilization in 32-bit images. For uncompressed files, the image data size is simply width multiplied by height multiplied by the pixel depth in bytes (depth divided by 8), appended directly after the color map to form the total payload before any optional areas.[2] This structure may be encoded with run-length encoding (RLE) for compression in applicable image types, but the underlying pixel organization remains row-major and channel-contiguous.[11]| Pixel Depth | Format Description | Channel Order (Uncompressed) | Typical Use |
|---|---|---|---|
| 8 bits | Grayscale or palettized | Single byte per pixel (intensity or index) | Monochrome or indexed color images[2] |
| 24 bits | True-color RGB | Blue (1 byte), Green (1 byte), Red (1 byte) | Standard color raster without alpha[11] |
| 32 bits | True-color RGBA | Blue (1 byte), Green (1 byte), Red (1 byte), Alpha (1 byte) | Color with transparency support[2] |
Optional Areas
The optional areas in the Truevision TGA file format follow the image data and provide space for supplementary metadata, custom extensions, and file termination markers, enabling enhanced functionality without altering the core structure. These areas—comprising the developer area, extension area, and file footer—are non-mandatory and were introduced in version 2.0 to support advanced features like author information and thumbnails while maintaining backward compatibility with earlier versions.[2][7] The developer area is an optional, variable-length section reserved for custom vendor-specific data, such as proprietary tags or application-defined information. It immediately follows the image data if present and consists of a directory of tags, where the first 2 bytes indicate the number of tags (0 to 65,535), followed by that many directory entries. Each entry includes a 2-byte tag number (0–32,767 for general developers, 32,768–65,535 reserved for Truevision), a 4-byte offset from the start of the file to the tag data, and a 4-byte data size; the actual tag data appears elsewhere in the file, often in the developer area itself, and its interpretation depends on prior knowledge of the tag format. This area is typically unused in standard implementations but allows for extensibility, with its presence and location indicated by a 4-byte offset in the file footer (0 if absent).[7][2] Introduced in version 2.0, the extension area is an optional 495-byte fixed structure (preceded by a 2-byte size field set to 495) that stores standardized metadata, followed by variable-length optional data such as thumbnails and scan line tables. It begins with fields for identification and descriptive information, as detailed in the table below:| Offset | Size (bytes) | Field Name | Description |
|---|---|---|---|
| 0 | 2 | Extension Size | Fixed value of 495 for the core structure. |
| 2 | 41 | Author Name | NULL-terminated string (40 characters max) for the image author's name. |
| 43 | 324 | Author Comments | Four 80-character NULL-terminated lines for author notes. |
| 367 | 12 | Date/Time Stamp | Six 2-byte SHORT fields: month (1–12), day (1–31), year (0–9999), hour (0–23), minute (0–59), second (0–60, including leap seconds). |
| 379 | 41 | Job Name | NULL-terminated string (40 characters max) for job or project identifier. |
| 420 | 6 | Job Time | Three 2-byte SHORT fields: hours (elapsed time), minutes (0–59), seconds (0–60). |
| 426 | 41 | Software ID | NULL-terminated string (40 characters max) identifying the creating software. |
| 467 | 3 | Software Version | 2-byte SHORT for version number (value × 100, e.g., 100 for 1.00) + 1-byte ASCII letter for sub-version (e.g., 'A'). |
| 470 | 4 | Key Color | 4-byte LONG in A:R:G:B order for matte or background color. |
| 474 | 4 | Pixel Aspect Ratio | Two 2-byte SHORT fields: numerator and denominator for pixel aspect ratio (width/height). |
| 478 | 4 | Gamma Value | Two 2-byte SHORT fields: numerator and denominator for gamma correction (0.0 to 10.0). |
| 482 | 4 | Color Correction Offset | Offset to a 256-entry, 4-byte-per-entry LUT (A:R:G:B) for color table correction. |
| 486 | 4 | Postage Stamp Offset | Offset to thumbnail image data (up to 8-bit grayscale or indexed, dimensions derived from header). |
| 490 | 4 | Scan Line Table Offset | Offset to a table of 4-byte scan line offsets for irregular image layouts (e.g., non-rectangular). |
| 494 | 1 | Attributes Type | Specifies alpha channel usage (0: no alpha; 1: undefined, ignore; 2: undefined, retain; 3: useful alpha; 4: pre-multiplied alpha; 5-127: reserved; 128-255: unassigned). |
Features and Capabilities
Supported Data Types
The Truevision TGA format supports a variety of image data types through its Image Type field (byte 2 in the header), which uses specific codes to indicate the structure and compression of the pixel data. These include type 0 for files with no image data included, type 1 for uncompressed color-mapped images, type 2 for uncompressed true-color (RGB) images, type 3 for uncompressed grayscale (black-and-white) images, type 9 for run-length encoded (RLE) color-mapped images, type 10 for RLE true-color images, and type 11 for RLE grayscale images.[2][11] TGA files accommodate various bit depths per pixel, as specified in the header's Bits Per Pixel field (byte 16), which is an 8-bit value allowing theoretical depths from 1 to 255 bits, though practical implementations are limited to common values such as 8 bits for grayscale or indexed (palette-based) images, 15 or 16 bits for RGB with 5-6 bits per channel (often 5:5:5 RGB or 5:6:5 RGB, sometimes with a 1-bit alpha), 24 bits for full RGB (8 bits per channel), and 32 bits for RGBA (24-bit RGB plus 8-bit alpha).[2][11][1] Special features enhance flexibility in representing image data. The Image Descriptor byte (byte 17) includes bits 3-0 to specify 0-15 attribute (alpha) bits per pixel (commonly 0, 1, or 8 in practice) for transparency support, particularly in 16-bit (1-bit alpha) and 32-bit (8-bit alpha) formats, while bits 5 and 4 control pixel orientation—bit 5 indicating bottom-to-top (0) or top-to-bottom (1) scan order, and bit 4 indicating right-to-left (0) or left-to-right (1) direction. For palette-based images (types 1 and 9), a color map is included when the Color Map Type field (byte 1) is set to 1, supporting up to 256 entries with 15, 16, 24, or 32 bits per entry, as seen in formats like VDA/D or TARGA M8.[2][11] The format is inherently limited to single-raster images with no native support for multiple images or animations within one file.[2][1]| Image Type Code | Description | Compression |
|---|---|---|
| 0 | No image data | N/A |
| 1 | Uncompressed color-mapped | None |
| 2 | Uncompressed true-color (RGB) | None |
| 3 | Uncompressed grayscale | None |
| 9 | RLE color-mapped | RLE |
| 10 | RLE true-color (RGB) | RLE |
| 11 | RLE grayscale | RLE |
Compression Methods
The Truevision TGA format employs a run-length encoding (RLE) scheme to achieve data compression, specifically designed for raster images with repetitive pixel values. This method encodes sequences of identical pixels into compact packets, making it particularly suitable for computer-generated graphics featuring large uniform areas. The RLE is lossless, ensuring no data degradation upon decompression, and is applied exclusively to the image data portion of the file, leaving the color map data uncompressed.[2][11] The RLE mechanism operates on a packet-based structure, where each packet begins with a single-byte repetition count. The high bit (bit 7) of this byte determines the packet type: set to 1 for a run-length (repetition) packet or 0 for a raw (non-repetitive) packet. The lower 7 bits represent the length minus one, allowing counts from 1 to 128 pixels per packet. In a run-length packet, this is followed by a single pixel value (whose size matches the image's pixel depth, such as 1-4 bytes for 8-32 bits), which is then replicated for the specified count. A raw packet, conversely, is followed by that many unique pixel values in sequence. This encoding is uniform across varying pixel depths, with the pixel size determined by the file's specifications, and packets can span scan lines or cover the entire image as needed.[2][11] Decoding proceeds sequentially by traversing the compressed data stream: for each packet, the repetition count is calculated as(packet byte & 0x7F) + 1, the type is checked via the high bit, and pixels are either replicated or read directly accordingly. This process applies to image type codes 9 (RLE-compressed color-mapped), 10 (RLE-compressed true-color), and 11 (RLE-compressed monochrome), enabling efficient storage without requiring separate compressed and uncompressed file variants. The simplicity of this adaptive scheme—switching between run-length and raw packets—provides significant file size reductions for suitable images; for instance, 128 identical 24-bit pixels can shrink from 385 bytes uncompressed to just 4 bytes.[2][11]