X BitMap
View on Wikipedia
| X BitMap | |
|---|---|
A sample XBM file | |
| Filename extension | .xbm |
| Internet media type |
image/x-xbitmap, image/x-xbm[1] |
| Uniform Type Identifier (UTI) | public.xbitmap-image[2] |
| Type of format | Image file formats |
| Extended from | C (programming language) |
| Extended to | X PixMap (XPM) |
In computer graphics, the X Window System used X BitMap (XBM), a plain text binary image format, for storing cursor and icon bitmaps used in the X GUI.[3] The XBM format is superseded by XPM, which first appeared for X11 in 1989.[4]
Format
[edit]XBM files differ markedly from most image files in that they take the form of C source files. This means that they can be compiled directly into an application without any preprocessing steps, but it also makes them far larger than their raw pixel data. The image data is encoded as a comma-separated list of byte values, each written in the C hexadecimal notation, '0x13' for example, so that multiple ASCII characters are used to express a single byte of image information.[5]
XBM data consists of a series of static unsigned char arrays containing the monochrome pixel data. When the format was in common use, an XBM typically appeared in headers (.h files) which featured one array per image stored in the header. The following piece of C code exemplifies the XBM file Blarg displayed in the panel at right:
#define test_width 16
#define test_height 7
static unsigned char test_bits[] = {
0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55, 0xa5, 0x93, 0xc5, 0x00, 0x80,
0x00, 0x60 };
In place of the usual image-file-format header, XBM files has two or four #define statements. The first two #defines specify the height and width of the bitmap in pixels. The second two, if any, specify the position of any hotspot within the bitmap. (In the case of bitmapped cursors, the "hotspot" refers to the position of the cursor "point", generally at 0,0.)
XBM image data consists of a line of pixel values stored in a static array. Because a single bit represents each pixel (0 for white or 1 for black), each byte in the array contains the information for eight pixels, with the upper left pixel in the bitmap represented by the low bit of the first byte in the array. If the image width does not match a multiple of 8, the extra bits in the last byte of each row are ignored.
Support
[edit]Some web browsers support displaying XBM images as a holdover from the early days of the World Wide Web, when XBM was the minimal non-proprietary image file format. The Arena web browser had full support since version 0.3.34 (25 July 1997).[6] XBM support was removed from Internet Explorer 6, Mozilla Firefox 3.6,[7] and WebKit-based browsers.[8] There is a strong indication that Chromium (and therefore, also, Google Chrome) does not support XBM.[9] Documentation for Opera 2.12 and 6.0 indicates that XBM was at least previously supported.[10][11]
Some image viewers/converters, e.g., XnView, FFmpeg and IrfanView, support XBM.[12] A 48ร48 XBM can be converted to Ikon and eventually X-Face with Netpbm tools.[13]
Despite having been superseded by the XPM format, XBM is still used by some modern but lightweight window managers like Openbox to define simple button images in a window's title bar, such as the iconify/minimize, restore, and maximize buttons.[14] XBM is also used in embedded processing (microControllers) to display Icons used in GUIs.[15] ImageMagick[16] supports converting images both to and from XBM. GIMP may be used to create or modify images using the XBM format, and also supports converting images to and from the XBM format.
See also
[edit]References
[edit]- ^ .xbm MIME type not registered at IANA
- ^ "System-Declared Uniform Type Identifiers". Uniform Type Identifiers Reference. Apple Inc.
- ^ Steve Kinzler (2005). "Picons Archive". Retrieved 6 January 2014.
picons are in either monochrome XBM format or color XPM and GIF formats
- ^ Daniel Dardailler (15 July 1996). "The XPM Story". Colas Nahaboo and Arnaud Le Hors. Archived from the original on 2 January 2014. Retrieved 1 January 2014.
- ^ James D. Murray; William van Ryper (April 1996). Encyclopedia of Graphics File Formats, Second Edition. O'Reilly. ISBN 1-56592-161-5. Retrieved 27 February 2014.
- ^ QingLong, Lu (24 March 1998). "Arena change history". Yggdrasil Computing. Archived from the original on 28 February 2003. Retrieved 27 February 2014.
- ^ "504822 โ Remove XBM support from Mozilla". Mozilla. 12 July 2010. Retrieved 22 October 2014.
- ^ "Bug 27823 โ Remove XBM support". WebKit. 12 January 2010. Retrieved 22 October 2014.
- ^ "Issue 372898: Chrome displays broken image icon when given direct link to XBM image". chromium - An open-source project to help move the web forward. 26 June 2014. Archived from the original on 21 December 2014. Retrieved 22 October 2014.
- ^ "Opera Software ASA - Opera version history". Opera Software. 5 February 2013. Retrieved 22 October 2014.
- ^ "Changelog for Opera 6.0 for Unix TP 1". Opera Software. 26 November 2001. Retrieved 22 October 2014.
- ^ "Image Formats". FFmpeg General Documentation. 2014. Retrieved 23 February 2014.
- ^ Jeff Dairiki. "Online X-Face Converter". Retrieved 2 March 2014.
- ^ "Openbox Theme Documentation". Archived from the original on 13 October 2014. Retrieved 8 October 2014.
- ^ olikraus. "U8g2 library reference". GitHub. Retrieved 22 May 2017.
- ^ Aseem Kishore (8 May 2010). "Convert Images Between Formats via the Command Line in Ubuntu". Retrieved 22 May 2017.
X BitMap
View on Grokipedia.xbm or .h extension, are typically embedded directly into application source code for easy compilation and use, enabling developers to include lightweight, resolution-independent icons without relying on external image loaders.[2][1] XBM's simplicity made it ideal for resource-constrained systems, though it supports multiple images per file if each has a unique array name, and utilities like bitmap (from the X.Org distribution) allow editing, viewing, and conversion to/from ASCII representations for tasks such as printing or data exchange.[1] Despite its age, XBM persists in legacy X11 applications and open-source projects, serving as a precursor to more advanced formats like XPM, but it is limited to binary (on/off) pixels without grayscale or color support.[2]
Overview
Definition and Purpose
X BitMap (XBM) is a monochrome, bi-level raster image format specifically designed for use within the X Window System, representing images using only two colors: black and white.[2] This format encodes pixel data in a 1-bit depth structure, where each bit corresponds to a pixel that is either set (foreground, typically black) or unset (background, typically white).[3] The primary purpose of XBM is to store simple black-and-white bitmaps, with a focus on small graphics such as icons, cursors, and tiles employed in X11 graphical user interfaces.[4] It facilitates efficient handling of these elements in resource-constrained environments typical of early Unix-like systems, enabling quick loading and rendering without complex color processing.[2] Developed as part of the X Window System, XBM contributed to the foundational graphics capabilities of Unix-like operating systems by providing a lightweight mechanism for bitmap resources in networked, multi-user displays.[2] XBM files adopt a plain-text format that resembles C programming language code snippets, defining the bitmap data as static arrays of unsigned characters for direct inclusion in application source code.[3] Its strict monochrome nature limited applicability for more vibrant graphics, paving the way for successors like the X PixMap (XPM) format to support color images in X11 applications.[5]Key Characteristics
The X BitMap (XBM) format is inherently monochrome, supporting only two colorsโforeground and background, which are typically rendered as black and whiteโdue to its single-bit-per-pixel representation.[2][6] This binary structure limits each pixel to a 1 or 0, enabling efficient storage of simple bit patterns but precluding any grayscale or multicolored imagery.[1] As a text-based format, XBM files are encoded in ASCII and structured as compilable C-language data arrays, allowing direct inclusion in application source code without additional processing.[2][6] These arrays pack bits into bytes (8 pixels per byte in the X11 variant), resulting in compact file sizes that are ideal for small graphics like icons and cursors.[1] Files conventionally use the .xbm extension to denote their purpose.[6] XBM employs no compression algorithms, relying solely on its bit-packed efficiency for minimal footprint, and offers no support for color palettes or depth beyond monochrome.[2] These constraints make the format lightweight yet unsuitable for representing complex or detailed images, emphasizing its role in basic graphical elements within the X Window System.[6]History
Origins in X Window System
The X BitMap (XBM) format emerged in the mid-1980s during the initial development of the X Window System at MIT's Project Athena, debuting with the X10 release in 1985 and receiving refinements in the X11 protocol standardized in 1987.[7][8] This timing aligned with the rapid proliferation of Unix workstations equipped with bitmap displays, necessitating a lightweight graphics primitive for distributed computing environments.[9] XBM was specifically created to offer a simple, portable mechanism for defining monochrome bitmaps, represented as C-language data arrays that could be directly compiled into applications.[2][10] Its primary role was to store cursor shapes, icon bitmaps, and related elements essential for user interface components like window decorations, menus, and pointers, ensuring compatibility across heterogeneous Unix systems without reliance on proprietary hardware.[10] This text-based format, with data encoded in hexadecimal or binary constants, prioritized ease of editing and inclusion in source code over complex rendering capabilities.[2] As one of the earliest standardized graphics formats tailored for networked displays, XBM supported the X Window System's core philosophy of network transparency, allowing bitmaps to be transmitted and rendered remotely on bitmap servers.[10][8] The format's two variantsโX10, using 16-bit words, and X11, adopting 8-bit bytesโreflected iterative improvements to align with evolving protocol needs, though the X10 version became obsolete shortly after.[2] Later extensions, such as the X PixMap (XPM) format introduced in 1989, built upon XBM by adding color support while maintaining backward compatibility.[2]Development and Evolution
The X BitMap (XBM) format was standardized as part of X11 Release 1 in September 1987, marking its formal integration into the X Window System protocol and the Xlib library for handling monochrome bitmaps used in icons and cursors.[11][2] This release established XBM as the primary method for embedding bitmap data directly into C source code, with functions like XCreateBitmapFromData and XReadBitmapFile becoming core components of Xlib to facilitate bitmap creation and file I/O.[12] Its monochrome limitations, which restricted it to black-and-white representations, prompted the development of the X PixMap (XPM) format in 1989 as a color extension, significantly reducing XBM's prominence within the X ecosystem.[13] XPM, inspired by XBM's ASCII-based structure, allowed for multi-color pixmaps and was quickly adopted for applications requiring visual richness beyond binary images.[13] Subsequent X11 releases, such as Release 6 in 1994, included minor enhancements to Xlib's bitmap handling for improved server integration and portability across hardware, but introduced no substantial changes to the XBM specification itself.[14] These updates focused on refining protocol efficiency and library APIs rather than evolving the format, maintaining XBM's role in legacy monochrome contexts.[12] By the mid-1990s, XBM's usage declined sharply with the emergence of versatile web-oriented formats like PNG, which offered lossless compression, transparency, and color support suitable for broader digital applications, confining XBM primarily to legacy X11 software.[15][2]Technical Specifications
File Structure
The X BitMap (XBM) file format is a plain text representation structured as a C source code fragment, intended for direct inclusion in applications via the C preprocessor. It commences with two required #define preprocessor directives that declare the bitmap's dimensions:#define name_width width_value and #define name_height height_value, where "name" conventionally matches the file's basename without extension, and the values specify the pixel dimensions in integers.[2] Optionally, for bitmaps used as cursors or icons, two additional #define directives specify the hotspot coordinates: #define name_x_hot x_value and #define name_y_hot y_value, indicating the pixel position (0-based) of the hotspot relative to the top-left corner. For instance, a 16ร16 bitmap would include #define icon_width 16 followed by #define icon_height 16, potentially preceded by hotspot definitions if applicable.[2]
Following the header directives, the file contains a single static array declaration for the pixel data: static unsigned char name_bits[] = { ... };, where the array holds the bitmap's bits as a comma-separated sequence of unsigned character values, typically in hexadecimal (prefixed with 0x) or octal notation.[2] The array encapsulates the entire image in scanline order, with no delimiters between rows. The format assumes a fixed 1-bit monochrome depth, providing no additional metadata for color mapping, compression, or other attributes beyond the specified dimensions.[2]
Pixel data is packed densely at 8 bits per byte, with each byte representing one row segment from left to right and top to bottom. The bit order employs a most-significant-bit-first (MSB) convention, wherein the leftmost (highest-indexed) bit in a byte is the most significant and corresponds to the leftmost pixel in that byte.[2] Each scanline is padded to complete byte boundaries, with any trailing unused bits in the final byte of a row set to zero and ignored during rendering.[2]
To illustrate, consider a minimal 8ร8 bitmap file named "example.xbm":
#define example_width 8
#define example_height 8
static unsigned char example_bits[] = {
0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18
};
This encodes a simple diamond pattern, where each byte fills one row (no padding needed due to byte-aligned width). The syntax rules derive directly from the X Window System protocol's bitmap encoding, ensuring the data aligns with server-side pixmap creation requests like CreatePixmap or PutImage in XYBitmap format.[16]
Data Representation
In the X BitMap (XBM) format, pixel data is encoded as a monochrome bitmap where each bit corresponds to a single pixel, with a value of 1 indicating a foreground pixel (typically rendered as black or opaque) and 0 indicating a background pixel (typically rendered as white or transparent).[17] This binary representation allows for compact storage of simple icons and cursors, as the entire image is defined solely by these bit values without color depth or palette information.[18] The packing scheme organizes the bitmap data row by row, scanning from left to right and top to bottom, with bits packed into bytes where the leftmost pixel in each row aligns with the most significant bit (MSB) of the first byte.[19] Within each byte, the bits proceed from MSB to least significant bit (LSB), representing consecutive pixels from left to right; subsequent bytes continue this pattern until the row is complete.[17] If the image width is not a multiple of 8 pixels, the row is right-padded with zero bits to complete the final byte, ensuring each row's data spans an integral number of bytes equal to .[18] These padding bits are set to 0 and do not affect the visible image, as any extra bits beyond the specified width are ignored during rendering.[19] In the context of the X Window System (X11), the bitmap data is interpreted to define opaque and transparent regions for graphics operations, such as creating pixmaps via functions likeXCreatePixmapFromBitmapData, where 1 bits map to the foreground color and 0 bits to the background color provided by the application.[18] The origin is implicitly at the top-left corner of the bitmap, with no explicit coordinate system or transformation specified in the data itself; dimensions are defined in the file header preceding the bit array.[17] This structure ensures compatibility with X11's server-side rendering, where the bitmap serves as a mask for drawing tiles, stipples, or cursors without additional metadata for positioning beyond the hotspot coordinates (if present).[19]
Usage
Role in X11 Graphics
In the X Window System, X BitMap files are loaded into pixmaps using Xlib functions such asXReadBitmapFile, which reads a bitmap file in the standard X11 format, creates a pixmap of the appropriate depth (typically 1 for monochrome), and returns the pixmap ID along with dimensions and hotspot coordinates if specified.[20] Alternatively, XCreateBitmapFromData allows direct creation of a bitmap pixmap from in-memory data embedded in C programs, often as hexadecimal arrays generated from X BitMap files via tools like XWriteBitmapFile.[21] These functions enable efficient integration of simple graphical elements into X11 applications by converting the file's binary data into server-side resources suitable for rendering.
Once loaded as pixmaps, X BitMaps serve key roles in X11 graphics, particularly for creating icons and window decorations. For instance, a bitmap pixmap can be set as a window's background using XSetWindowBackgroundPixmap, which tiles the pixmap across the window area and triggers repainting as needed, providing a lightweight method for patterned or icon-based backgrounds without requiring complex drawing operations.[22] Similarly, bitmaps are commonly used for icons in user interfaces, where they define small, fixed-shape graphics for buttons, menus, or application symbols, leveraging their off-screen storage to minimize redraw overhead.[1]
For cursor definition, X BitMaps are transformed into cursors via XCreatePixmapCursor, which takes a source bitmap pixmap (for the cursor shape) and an optional mask bitmap (to control transparency), along with foreground and background colors to map the binary pixels.[23] This approach allows custom cursors beyond predefined font-based ones (like those from XCreateFontCursor), enabling developers to define precise hotspots and shapes from X BitMap data for interactive elements such as pointers or selection tools. Due to its monochrome constraint limiting it to binary graphics, X BitMap excels in scenarios requiring stark, high-contrast visuals rather than color gradients.
The simplicity of the X BitMap formatโconsisting of ASCII headers followed by portable hexadecimal dataโensures high portability across different X servers and implementations, as it avoids platform-specific byte orders or dependencies beyond standard Xlib support.[19] This portability makes it ideal for distributing graphical assets in X11 environments. In higher-level toolkit libraries, such as Xt Intrinsics and Motif, X BitMaps are routinely employed for UI elements; for example, Motif's XmGetPixmap function loads them directly into pixmaps for labels, toggle buttons, and push buttons, where resources like XmNlabelPixmap or XmNselectPixmap assign them to widget states for consistent iconography.[24]
Applications Beyond Icons
X BitMap (XBM) files, due to their structure as plain text C language arrays, enable direct embedding into C programs as constant data for rendering simple monochrome graphics without requiring external file loading. This approach was particularly useful in resource-constrained Unix environments for incorporating bitmaps into applications, such as drawing tools and early games. For instance, the xfig vector graphics editor utilizes XBM imports to apply coloring to bitmap objects within its interactive editing workflow.[25][2] Conversion utilities facilitate interoperability between XBM and other bitmap formats, extending its utility in legacy graphics pipelines. The pbmtoxbm tool, part of the Netpbm suite since 1988, converts Portable Bitmap (PBM) images to X11-compatible XBM output, supporting both X10 and X11 variants for backward compatibility in Unix-based image processing.[26] In the early days of the web, XBM served as one of the initial image formats supported by HTML via the<IMG> tag, alongside GIF, allowing monochrome icons and simple graphics to be embedded in documents. The HTML 2.0 specification explicitly demonstrates this with examples like <IMG SRC="triangle.xbm" ALT="Warning:"> for inline image display and image maps.[27][5]
XBM plays a niche role in digital preservation efforts for 1980s and 1990s Unix software, where it stores graphical assets like cursors and bitmaps in archived distributions, ensuring fidelity to original interfaces in emulated or historical reconstructions. Its text-based, human-readable format aids long-term accessibility without proprietary dependencies.
Support and Compatibility
Software and Library Integration
Xlib, the foundational C library for the X Window System, provides native functions for reading and writing XBM files, including XReadBitmapFile for loading bitmap data from an XBM file into a pixmap and XWriteBitmapFile for saving pixmap data to an XBM file.[20] These functions parse the C-like syntax of XBM files directly, enabling seamless integration in X11 client applications for handling monochrome icons and cursors.[28] The XCB library, a modern replacement for Xlib emphasizing efficiency and direct protocol access, supports XBM through its image module, which includes functions like xcb_image_create for creating images in XBM format and handling scanline padding and bit order specific to the format.[29] This allows developers to read and write XBM data with lower overhead than Xlib, particularly in threaded or performance-critical applications.[30] ImageMagick, a widely used open-source suite for image processing, natively supports XBM as both input and output formats via its convert command, which can transform XBM files to and from other formats like PNG or JPEG while preserving the monochrome bitmap structure.[31] For example, the commandconvert input.xbm output.png demonstrates straightforward conversion, making it a staple tool for batch processing legacy X11 bitmaps in workflows.[31]
GIMP, the GNU Image Manipulation Program, includes built-in import and export capabilities for XBM files, allowing users to open monochrome bitmaps for editing and save them back in XBM format through the File > Export As dialog, with support dating back to early versions for compatibility with X11 graphics.[32] This integration facilitates pixel-level manipulation of XBM icons within a full-featured raster editor.[33]
Netpbm, a collection of Unix utilities for portable image manipulation, offers dedicated tools like xbmtopbm for converting XBM files to the portable bitmap (PBM) format and pbmtoxbm for the reverse, enabling efficient handling of XBM in pipeline-based processing without proprietary dependencies. These utilities respect XBM's bit-ordering and padding conventions, supporting monochrome image analysis and conversion in command-line environments.[34]
Tcl/Tk provides built-in support for XBM through the image create bitmap command, which accepts an XBM file via the -file option to load the bitmap data directly into Tk widgets like buttons or labels for rendering in graphical user interfaces.[35] This native handling simplifies embedding XBM icons in cross-platform Tk applications without additional extensions.[36]
The Perl GD module, an interface to the GD graphics library, supports reading and writing XBM files using constructors like GD::Image->newFromXbm for loading and the $image->xbm method for output, allowing programmatic creation and manipulation of monochrome bitmaps in Perl scripts.[37] It automatically recognizes XBM among other formats, making it suitable for server-side image generation involving X11-compatible assets.[37]
For C and C++ development beyond core X11 libraries, standalone implementations like the single-header xbm_format library provide lightweight reading and writing of XBM files, parsing the format's C array structure without requiring full Xlib linkage for embedded or minimal environments.[38]
In desktop environments, KDE and GNOME historically utilized XBM for icon themes and cursors in their early implementations, such as KDE 1.x and GNOME 1.x, but this support has been deprecated in favor of scalable vector formats like SVG to accommodate high-DPI displays. Legacy XBM assets may still appear in older theme packages, though modern releases prioritize PNG or SVG equivalents.