VIPS has its own very simple file format. It is used inside VIPS to hold images during computation. You can save images in VIPS format if you want, but the VIPS format is not widely used and you may have problems reading your images into other packages.
If you intend to keep an image, it’s much better to save it as TIFF, JPEG, PNG or PBM/PGM/PPM. VIPS can transparently read and write all these formats.
All VIPS image files start with a 64-byte header giving basic information about the image dimensions, see Table 1.1. This is followed by the image data. This is usually just the pixel values in native format (ie. the byte order used by the machine that wrote the file) laid out left-to-right and top-to-bottom. After the image data comes a block of optional XML which holds extra image metadata, such as ICC profiles and image history. You can use the command-line program header to extract the XML from an image and edvips to replace it, see the man pages.
The Type field, the Xres/Yres fields, and the Xoffset/Yoffset fields are advisory. VIPS maintains their value (if you convert an image to CIE L*a*b* colour space with im_XYZ2Lab(), for example, VIPS will set Type to be IM_TYPE_LAB), but never uses these values itself in determining the action of an image processing function. These fields are to help the user, and to help application programs built on VIPS which are trying to present image data to the user in a meaningful way.
The BandFmt, Coding and Type fields can take the values shown in tables 1.2, 1.3 and 1.4. The C++ and Python names for these values are slightly different, for historical reasons.
|
|
|
|
This type of image has Coding set to IM_CODING_NONE. The header is then followed by a large array of pixels, laid out left-to-right, top-to-bottom. Each pixel contains the specified number of bands. Each band has the specified band format, which may be an 8-, 16- or 32-bit integer (either signed or unsigned), a single or double precision IEEE floating point number, or a pair of single or double precision floats forming a complex number.
All values are stored in the host-machine’s native number representation (that is, either most-significant first, as in SPARC and 680x0 machines, or least-significant first, for Intel and DEC machines). The VIPS library will automatically byte-swap for you if necessary, but this can be slow.
All storage formats have other values for the Coding field. This release supports only IM_CODING_LABQ format.
IM_CODING_LABQ stores L*, a* and b* for each pixel, with 10 bits for L* and 11 bits for each of a* and b*. These 32 bits are packed into 4 bytes, with the most significant 8 bits of each value in the first 3 bytes, and the left-over bits packed into the final byte as 2:3:3.
This format is a little awkward to process. Some VIPS functions can work directly on IM_CODING_LABQ images (im_extract(), for example), but most will require you to unpack the image to one of the computation formats (for example with im_LabQ2Lab()) first.