Commit a83791be authored by Sven Claussner's avatar Sven Claussner

Review, amend and update the XCF file format spec and parasites.txt

XCF spec:
- Update to GIMP 2.8.10
- Clarify role of file formats in the save-vs.-export-context
- Rearrange outline
- Collect infos on basic concepts in one chapter
- Add table of contents
- Add File format version history
- Add note on image size
- Add open questions and TODOs
- Sort properties alphabetically
- Unify tiles and hierarchy examples
- Wording
- Cosmetic cleanups

Update parasites.txt:
- Replace SVN->Git
- Update contact e-mail address
- Add table of contents
parent ca0dc0ac
===================================
Compositing and layer modes in GIMP
===================================
This document describes the process of compositing layers and the layer modes
in GIMP.
License
-------
This is free documentation; you can modify and/or redistribute
it according to the terms of the GNU General Public License
as published by the Free Software Foundation, either version
2 of the license, or (at your option) any later version.
About this document
-------------------
This document was originally written by Henning Makholm and part of the
XCF file format specification. Because the topics here are more general
in the context of GIMP they have been moved into a separate document.
9. COMPOSITING AND LAYER MODES
===============================
This section describes the "flattening" process that GIMP applies
when a multi-layer image is displayed in the editor or exported to
other image file formats. It is present for reference only; an XCF
consumer may well elect to do something different with pixel data from
the layers than flattening them.
Most XCF consumers will need to react to the layer mode property of
each layer; such a reaction must be informed by knowledge of how the
different layer modes affect the flattening process. In some
applications it might be acceptable for an XCF consumer to refuse
processing images with layer modes other than "Normal", but such an
application will probably not be considered fully XCF capable by its
users.
In this section we consider primary color (or grayscale) intensities
and alpha values for pixels to be real numbers ranging from 0.0 to
1.0. This makes many of the formulas easier; the reader is asked to
keep in mind that a (linear) conversion from the integral 0..255 scale
of the actual XCF scale is implied whenever data from the XCF file is
mentioned.
Any practical implementation of the computations specified below may
suffer rounding errors; this specification do not detail how these are
to be handled. GIMP itself rounds values to an integral number of
255ths at many points in the computation. This specification does not
specify exactly which these points are, and authors of XCF renderers
that aim to reproduce the effects of GIMP's flattening down to the
least significant bits are referred to studying its source code.
In the description below, the variable letter "a" is used for alpha
values. The variable letter "r", "g", "b" are used for primary
intensities, "y" is used for grayscale intensities, and "i" is used
for color map indexed. The letter "c" is used for the complete
color information for a pixel; depending on the color mode of the
image that is either an (r,g,b) triple, a y, or a c.
The flattening process works independently for each pixel in the
canvas area. The description of some layer modes in the GIMP manual
may give the impression that they involve filters that let pixels
influence neighbor pixels, but that is not true.
This description does not attempt to preserve the color information
for completely transparent pixels in a layer. If an application uses
this color information, it should document explicitly how it behaves
when transparent pixels from several different layers cover the same
point of the canvas.
Flattening overview
-------------------
This is how to compute the flattened result for a single pixel
position (in theory, that is - efficient implementations will of
course follow this procedure or an equivalent one for many pixels in
parallel):
1. Initialize a "working pixel" (a1,c1) to be completely transparent
(that is, a1=0.0 and the value of c1 is immaterial).
2. Do the following for each visible layer in the image, starting with
the one that comes LAST in the master layer list:
3. Ignore the layer if it is the floating selection, or if it
does not overlap the pixel position in question.
4. Let (a2,c2) be the pixel data for the layer at the pixel
position in question. If the layer does not have an alpha
channel, then set a1 to 1.0.
5. If the layer is the one that the floating selection is attached
to and the floating selection overlaps the pixel position in
question, then do the following:
6. Let (a3,c3) be the pixel data for the floating selection
layer at the pixel position in question.
7. If there is a selection channel, then let x be its value
at the pixel position in question, and set a3 to a3*x.
8. Let m3 be the layer mode of the floating selection.
9. Set (a2,c2) to COMPOSITE(a2,c2, a3,c3,m3).
The COMPOSITE function is defined below.
10. If the layer has a layer mask and it is enabled, then let x be
the value of the layer mask at the pixel position in question,
and set a2 to a2*x.
11. Let m2 be the layer mode of the layer.
12. If the layer is the bottommost visible layer (i.e., if it is
the last visible layer in the master layer list) and m2 is not
"Normal" or "Dissolve", then set m2 to "Normal".
13. Set (a1,c1) to COMPOSITE(a1,c1, a2,c2,m2).
The COMPOSITE function is defined below.
14. If the flattened image is to be shown against a background of
color c0, then actually visible pixel is
COMPOSITE(1.0,c0, a1,c1,Normal).
Note that unless all layers have mode Normal, it would give the
wrong result to start by initializing (a1,c1) to (1.0,c0).
Helper functions
----------------
The following auxiliary functions are used in the definition of
COMPOSITE below:
MIN(x1,...,xn) is the least value of x1...xn
MAX(x1,...,xn) is the largest value of x1..xn
MID(x1,...,xn) = (MIN(x1,...,xn)+MAX(x1,...,xn))/2
CLAMP(x) = if x < 0 then 0.0 else if x > 1 then 1.0 else x
BLEND(a1,x1, a2,x2) = (1-k)*x1 + k*x2
where k = a2/(1-(1-a1)*(1-a2))
Layer modes
-----------
This and the following sections define the COMPOSITE function used in
the general flattening algorithm.
"Normal" mode for RGB or grayscale images is the usual mode of
compositing in computer graphics with alpha channels. In indexed
mode, the alpha value gets rounded to either 1.0 or 0.0 such that
no colors outside the color map get produced:
COMPOSITE(a1,y1, a2,y2,Normal)
= ( 1-(1-a1)*(1-a2), BLEND(a1,y1, a2,y2) )
COMPOSITE(a1,r1,g1,b1, a2,r2,g2,b2,Normal)
= ( 1-(1-a1)*(1-a2), BLEND(a1,r1, a2,r2),
BLEND(a1,g1, a2,g2),
BLEND(a1,b1, a2,b2) )
COMPOSITE(a1,i1, a2,i2,Normal) = if a2 > 0.5 then (1.0,i2) else (a1,i1)
"Dissolve" mode corresponds to randomly dithering the alpha channel to
the set {0.0, 1.0}:
COMPOSITE(a1,c1, a2,c2,Dissolve) = chose pseudo-randomly between
(1.0,c2) with probability a2
(a1,c1) with probability 1-a2
These two modes are the only ones that make sense for all of the RGB,
grayscale and indexed color models. In the indexed color model, all
layer modes except Dissolve are treated as Normal.
Most layer modes belong to the following group, which makes sense for
RGB and grayscale images, but not for indexed ones:
COMPOSITE(a1,y2, a2,y2,m)
= ( a1, BLEND(a1,y1, MIN(a1,a2),f(y1,y2, m)) )
COMPOSITE(a1,r1,g1,b1, a2,r2,g2,b2,m)
= ( a1, BLEND(a1,r2, MIN(a1,a2),f(r1,r2, m)),
BLEND(a1,g1, MIN(a1,a2),f(g1,g2, m)),
BLEND(a1,b1, MIN(a1,a2),f(b1,g2, m)) )
when 3 <= m <= 10 or 15 <= m <= 21.
The following table defines f(x1,x2,m):
Multiply: f(x1,x2, 3) = x1*x2
Screen: f(x1,x2, 4) = 1-(1-x1)*(1-x2)
Overlay: f(x1,x2, 5) = (1-x2)*x1^2 + x2*(1-(1-x2)^2)
Difference: f(x1,x2, 6) = if x1 > x2 then x1-x2 else x2-x1
Addition: f(x1,x2, 7) = CLAMP(x1+x2)
Subtract: f(x1,x2, 8) = CLAMP(x1-x2)
Darken Only: f(x1,x2, 9) = MIN(x1,x2)
Lighten Only: f(x1,x2, 10) = MAX(x1,x2)
Divide: f(x1,x2, 15) = CLAMP(x1/x2)
Dodge: f(x1,x2, 16) = CLAMP(x1/(1-x2))
Burn f(x1,x2, 17) = CLAMP(1-(1-x1)/x2)
Hard Light: f(x1,x2, 18) = if x2 < 0.5 then 2*x1*x2 else 1-2*(1-x1)(1-x2)
Soft Light: f(x1,x2, 19) = (1-x2)*x1^2 + x2*(1-(1-x2)^2)
Grain Extract: f(x1,x2, 20) = CLAMP(x1-x2+0.5)
Grain Merge: f(x1,x2, 21) = CLAMP(x1+x2-0.5)
Note that the "Overlay" and "Soft Light" modes have identical effects.
In the "Divide", "Dodge", and "Burn" modes, division by zero should
be considered to produce a number so large that CLAMP(x/0) = 1 unless
x=0, in which case CLAMP(0/0) = 0.
The remaining four layer modes only make sense in the RGB color model;
if the color mode of the image is grayscale or indexed they will be
interpreted as Normal.
COMPOSITE(a1,r1,g1,b1, a2,r2,g2,b2,m)
= ( a1, BLEND(a1,r2, MIN(a1,a2),r0),
BLEND(a1,g1, MIN(a1,a2),g0),
BLEND(a1,b1, MIN(a1,a2),b0) )
where (r0,g0,b0) = h(r1,g1,b1, r2,g2,b2, m)
when 11 <= m <= 14.
For defining these modes, we say that
(r,g,b) has the _hue_ of (r',g',b')
if r' = g' = b' and r >= g = b
or there exist p and q such that p>=0 and r=p*r'+q and b=p*b'+q and g=p*g'+q
(r,g,b) has the _value_ of (r',g',b')
if MAX(r,g,b) = MAX(r',g',b')
(r,g,b) has the _HSV-saturation_ of (r',g',b')
if r' = g' = b' = 0 and r = g = b
or MIN(r,g,b) = MAX(r,g,b)*MIN(r',g',b')/MAX(r',g',b')
(r,g,b) has the _luminosity_ of (r',g',b')
if MID(r,g,b) = MID(r',g',b')
(r,g,b) has the _HSL-saturation_ of (r',g',b')
if r' = g' = b' and r = g = b
or MAX(r,g,b)-MIN(r,g,b) = MIN(MID(r,g,b),1-MID(r,g,b)) *
(MAX(r',g',b')-MIN(r',g',b'))/MIN(MID(r',g',b'),1-MID(r',g',b'))
Mode 11: Hue (H of HSV)
h(r1,g1,b1, r2,g2,b2, 11) is
if r2=g2=b2 then (r1,g1,b1) unchanged
otherwise: the color that has
the hue of (r1,g2,b2)
the value of (r1,g1,b1)
the HSV-saturation of (r1,g1,b1)
Mode 12: Saturation (S of HSV)
h(r1,g1,b1, r2,g2,b2, 12) is the color that has
the hue of (r1,g1,b1)
the value of (r1,g1,b1)
the HSV-saturation of (r2,g2,b2)
Mode 13: Color (H and S of HSL)
h(r1,g1,b1, r2,g2,b2, 13) is the color that has
the hue of (r2,g2,b2)
the luminosity of (r1,g1,b1)
the HSL-saturation of (r2,g2,b2)
Mode 14: Value (V of HSV)
h(r1,g1,b1, r2,g2,b2, 14) is the color that has
the hue of (r1,g1,b1)
the value of (r2,g2,b2)
the HSV-saturation of (r1,g1,b1)
\ No newline at end of file
PARASITE REGISTRY - 2007-10-18 PARASITE REGISTRY
================= =================
This document describes parasites in GIMP.
Table of contents
-----------------
Parasite registry
Table of contents
Audience
1. Namespace
2. Known prefixes
3. Known global parasites
4. Known image parasites
5. Known layer/drawable parasites
6. Parasite format
Audience
--------
This document is designed for the convenience of GIMP developers. This document is designed for the convenience of GIMP developers.
It does not need to concern users. It does not need to concern users.
>>>> If your plugin or script writes parasites, please >>>> If your plug-in or script writes parasites, please
>>>> amend this file in SVN or submit patches to >>>> amend this file in the Git repository or submit patches to
>>>> gimp-developer@scam.xcf.berkeley.edu >>>> gimp-developer-list@gnome.org
------------------------------------------------------------------ 1. NAMESPACE
*** NAMESPACE ============
Plug-in-specific data should be prefixed by the plug-in function name and Plug-in-specific data should be prefixed by the plug-in function name and
a slash, i.e. private data of plug_in_displace should be named like: a slash, i.e. private data of plug_in_displace should be named like:
...@@ -22,8 +46,9 @@ etc. ...@@ -22,8 +46,9 @@ etc.
Global data follows no strict rules. Global data follows no strict rules.
------------------------------------------------------------------
*** KNOWN PREFIXES: 2. KNOWN PREFIXES
=================
"tiff" : The standard GIMP TIFF plugin "tiff" : The standard GIMP TIFF plugin
"jpeg" : The standard GIMP JPEG plugin "jpeg" : The standard GIMP JPEG plugin
...@@ -31,8 +56,9 @@ Global data follows no strict rules. ...@@ -31,8 +56,9 @@ Global data follows no strict rules.
"dcm" : The standard GIMP DICOM plugin "dcm" : The standard GIMP DICOM plugin
"gimp" : For common and standard parasites "gimp" : For common and standard parasites
------------------------------------------------------------------
*** KNOWN GLOBAL PARASITES: 3. KNOWN GLOBAL PARASITES
=========================
"jpeg-save-defaults" (GLOBAL, PERSISTENT) "jpeg-save-defaults" (GLOBAL, PERSISTENT)
Default save parameters used by the JPEG plug-in. Default save parameters used by the JPEG plug-in.
...@@ -54,8 +80,9 @@ Global data follows no strict rules. ...@@ -54,8 +80,9 @@ Global data follows no strict rules.
plug-in should ask the user what to do. This parasite may be plug-in should ask the user what to do. This parasite may be
removed in a future version (assuming always yes). removed in a future version (assuming always yes).
------------------------------------------------------------------
*** KNOWN IMAGE PARASITES: 4. KNOWN IMAGE PARASITES
========================
"gimp-comment" (IMAGE, PERSISTENT) "gimp-comment" (IMAGE, PERSISTENT)
Standard GIF-style image comments. This parasite should be Standard GIF-style image comments. This parasite should be
...@@ -224,8 +251,9 @@ Global data follows no strict rules. ...@@ -224,8 +251,9 @@ Global data follows no strict rules.
AA is a two character ascii value representing the Dicom AA is a two character ascii value representing the Dicom
element's Value Represenation (VR) element's Value Represenation (VR)
------------------------------------------------------------------
*** KNOWN LAYER/DRAWABLE PARASITES: 5. KNOWN LAYER/DRAWABLE PARASITES
=================================
"gimp-text-layer" (LAYER, PERSISTENT) "gimp-text-layer" (LAYER, PERSISTENT)
The associated GimpText object serialized to a string. For The associated GimpText object serialized to a string. For
...@@ -242,8 +270,8 @@ Global data follows no strict rules. ...@@ -242,8 +270,8 @@ Global data follows no strict rules.
parasite, the contents of the parasite are loaded at startup. parasite, the contents of the parasite are loaded at startup.
------------------------------------------------------------------ 6. PARASITE FORMAT
*** PARASITE FORMAT: ==================
The parasite data format is not rigidly specified. For non-persistant The parasite data format is not rigidly specified. For non-persistant
parasites you are entirely free, as the parasite data does not survive the parasites you are entirely free, as the parasite data does not survive the
...@@ -259,7 +287,7 @@ non-persistant data might be fine as well): ...@@ -259,7 +287,7 @@ non-persistant data might be fine as well):
- Use character (string) data - Use character (string) data
Obvious to perl people but less so to C programmers: just sprintf your Obvious to Perl people but less so to C programmers: just sprintf your
data into a string (e.g. "SIZE 100x200 XRES 300 YRES 300") and store data into a string (e.g. "SIZE 100x200 XRES 300 YRES 300") and store
that in the parasite, and later sscanf it again. This often solves most that in the parasite, and later sscanf it again. This often solves most
of the problems you might encounter, makes for easier debugging and of the problems you might encounter, makes for easier debugging and
......
==================================== ====================================
SPECIFICATION OF THE XCF FILE FORMAT DOCUMENTATION OF THE XCF FILE FORMAT
==================================== ====================================
This document specifies the native image file format of GIMP. This document describes the native image file format of GIMP.
License
-------
Copyright Henning Makholm <henning@makholm.net>, 2006-07-11
This is free documentation; you can modify and/or redistribute
it according to the terms of the GNU General Public License
as published by the Free Software Foundation, either version
2 of the license, or (at your option) any later version.
Table of contents Table of contents
----------------- -----------------
Specification of the XCF file format Documentation of the XCF file format
Table of contents
License License
Table of contents
Audience
Scope
Status Status
Distinctions Version history
The name XCF
1. Basic data model 1. Basic concepts
Layers XCF file
Channels
2. Format concepts and data types
Basic data types Basic data types
Canvas
Color
Pixel data: Tiles
Pixel data: Levels of detail hierarchy
Channels
Layers
Layer masks
Properties Properties
Parasites Parasites
Selections
Floating selection
Tattoos
3. The master image structure 2. General properties
4. The layer structure 3. The Image structure
Layer properties Header
Image properties
5. The channel structure 4. The Channel structure
Channel properties Channel properties
6. The hierarchy structure 5. The Layer structure
Layer properties
6. The Hierarchy structure
Levels Levels
Tiles
7. Tile data organization 7. Tile data organization
Uncompressed tile data Uncompressed tile data
RLE compressed tile data RLE compressed tile data
8. Generic properties 8. Miscellaneous
The name XCF
9. Compositing and layer modes
Flattening overview
Helper functions
Layer modes
Audience
--------
License Audience of this document are developers of GIMP and other software that
------- reads and writes XCF files.
Copyright Henning Makholm <henning@makholm.net>, 2006-07-11
This is free documentation; you can modify and/or redistribute Scope
it according to the terms of the GNU General Public License -----
as published by the Free Software Foundation, either version
2 of the license, or (at your option) any later version. The XCF format is designed to store the whole state of GIMP that is specific to
one image (i.e., not the cut buffer, tool options, key bindings, etc.) and
is not undo data. This makes the full collection of data stored in an XCF file
rather heterogeneous and tied to the internals of GIMP.
Use of the XCF format by third-party software is recommended only as a way
to get data into and out of GIMP for which it would be impossible or
inconvenient to use a more standard interchange format.
Authors of third-party XCF-creating software in particular should take
care to write files that are as indistinguishable as possible from
ones saved by GIMP. The GIMP developers take care to make each
version of GIMP able to read XCF files produced by older GIMP versions,
but they make no special efforts to allow reading of XCF files created by
other software.
Interchanging image data with other applications is not goal of the XCF format.
For this use case GIMP opens and exports common images formats, like JPEG,
PNG and PSD.
TODO: Role of the ORA format in this context?
For the stated reasons and clarification GIMP _saves_ XCF files,
but _exports_ to other image formats.
Beware that CinePaint's native file format is called XCF, too. While it is
derived from the format described here, both formats differ in many details
and are _not_ mutually compatible.
This document does not describe the CinePaint XCF format.
For more information on that see http://www.cinepaint.org/more/docs/xcf.html
---------------------------------------------
T H I S I S A D R A F T O N L Y !
---------------------------------------------
Status Status
------ ------
This specification is an unofficial condensation and extrapolation of This specification is an unofficial condensation and extrapolation of
the XCF-writing and -reading code in version 2.2.11 of GIMP. As of the XCF-writing and -reading code in version 2.8.10 of GIMP. As of
this writing, it has not been approved or proofread by any GIMP this writing, it has not been approved or proofread by any GIMP
developer, though it has been written with the intention of developer, though it has been written with the intention of
contributing it to the GIMP project for use as official documentation. contributing it to the GIMP project for use as official documentation.
Some of the normative statements made below are enforced by the XCF Some of the normative statements made below are enforced by the XCF
reader in GIMP; others are just the author's informed guess about code in GIMP; others are just the author's informed guess about
"best practices" that would be likely to maximize interoperability "best practices" that would be likely to maximize interoperability
with future versions of GIMP. with future versions of GIMP.
Distinctions
------------
Beware that CinePaint's native file format is called XCF too. Version history
While the latter is derived from the format described here, the two formats ---------------
differ in many details and are not mutually compatible. This section lists the changes between file format versions in bigger terms.
See http://www.cinepaint.org/more/docs/xcf.html for more information. Details are denoted in the text.
The XCF format is designed to store the entire part of the state of Version 0:
GIMP that is specific to one image (i.e., not the cut buffer, tool Since GIMP 0.99.16, released on 15.12.1997.
options, key bindings, etc.) and is not undo data. This makes the The initial file format. Everything that is not listed in the following versions
full collection of data stored in an XCF file rather heterogeneous and is part of this.
tied to the internals of GIMP. Use of the format by third-party
software is recommended only as a way to get data into and out of
GIMP for which it would be impossible or inconvenient to use a more
standard interchange format.
Authors of third-party XCF-creating software in particular should take Version 1:
care to write files that are as indistinguishable as possible from Since GIMP 0.99.16, released on 15.12.1997.
ones saved by GIMP. The GIMP developers take care to make each Adds color maps. Chapter 3 "The image structure" describes the PROP_COLOR_MAP
version of GIMP able to read XCF files produced by older GIMP versions, property.
but they make no special efforts to allow reading of XCF files created by
other software.
The name XCF Version 2:
------------ Since GIMP 1.3.10, released on 07.11.2002.
Adds layer modes "Soft light", "Grain extract", "Grain merge" and painting
mode "Color Erase". In chapter 5 "The layer structure" the description of
the property PROP_MODE contains the new layer modes.
Improves path handling in GIMP 1.3.21 (releases on 5.10.2003).
Chapter 1 "Basic concepts" describes the path handling in general and
chapter 2 "General concepts" introduces the PROP_VECTORS property.
The name XCF honors GIMP's origin at the eXperimental Computing Version 3:
Facility of the University of California at Berkeley. Since GIMP 2.7.1, released on 29.06.2010.
Adds layer groups. The chapter 5 "The layer structure" describes the new
properties PROP_GROUP_ITEM, PROP_GROUP_ITEM_FLAGS and PROP_ITEM_PATH.
1. BASIC DATA MODEL 1. BASIC CONCEPTS
=================== =================
It is recommended that a software developer who wants to take full It is recommended that a software developer who wants to take full
advantage of the XCF format be deeply familiar with GIMP at least advantage of the XCF format be deeply familiar with GIMP at least
...@@ -115,77 +160,157 @@ as a user. The following high-level overview is meant to help those ...@@ -115,77 +160,157 @@ as a user. The following high-level overview is meant to help those
non-users who just need to extract pixel data from an XCF file get up non-users who just need to extract pixel data from an XCF file get up
to speed. to speed.
In general an XCF file describes a stack of _layers_ and _channels_ on
a _canvas_, which is just an abstract rectangular viewport for the
layers and channels.
Layers XCF file
--------
An XCF file is a sequence of bytes. In general an XCF file describes a stack of
layers and channels on a canvas.
It contains a series of data structures, the order of which is in general not
significant. The exception to this is that the main image structure must come at
the very beginning of the file, and that the tile data blocks for each drawable
must follow each other directly.
References _between_ structures in the XCF file take the form of
32-bit "pointers" that count the number of bytes between the beginning of
the XCF file and the beginning of the target structure. Note that therefore
the maximum address of a layer, channel, hierarchy or tile set is 2^32 - 1,
i.e. at 4 GB. Everything after will be lost. Currently this doesn't play a
role yet.
Each structure is designed to be written and read sequentially; many
contain items of variable length and the concept of an offset _within_
a data structure is not often relevant.
Basic data types
----------------
A WORD is a 32-bit integer stored as 4 bytes in big-endian order, i.e. with
the most significant byte first. The word is not necessarily aligned to an
offset within the XCF file that is a multiple of 4.
Depending on the context the word can be unsigned or (2's complement) signed.
UINT32 denotes unsigned words and INT32 denotes signed words in this document.
A FLOAT is stored as a 32-bit IEEE 754 single-precision floating-point number
in big-endian order.
A STRING is stored as follows:
uint32 n+1 Number of bytes that follow, including the zero byte
byte[n] ... String data in Unicode, encoded using UTF-8
byte 0 Zero marks the end of the string.
Exception: the empty string is stored simply as an uint32 with the
value 0.
Canvas
------ ------
A layer is a named rectangular area of pixels which has a definite A canvas is an abstract rectangular viewport for the layers and channels.
position with respect to the canvas. A layer may extend beyond the The image header stores the canvas' dimensions.
canvas or (more commonly) only cover some of it. Each pixel of the
layer has a color which is specified in one of three ways:
RGB: Three intensity values for red, green, and blue additive color
components, each on a scale from 0 to 255. The exact color space
is not specified. GIMP displays image data directly on PC
display hardware without any software correction, so in most
cases the intensity values should be considered nonlinear samples
that map to physical light intensities using a power function
with an exponent ("gamma") of about 2.5. (This is how PC hardware
commonly treat bit values in the video buffer, which incidentally
also has the property of making each 1/255th step about equally
perceptible to the human eye when the monitor is correctly
adjusted).
Beware, however, that GIMP's compositing algorithms (as
described in Section 8 below) implicitly treat the intensities
as _linear_ samples. The XCF file format currently has no support
for storing the intended gamma of the samples.
Grayscale: One intensity value on a scale from 0 (black) to 255
(white). Gamma considerations as for RGB.
Indexed: An 8-bit index into a color map that is shared between all
layers. The color map maps each index to an RGB triple which is
interpreted as in the RGB model.
All layers in an image must use the same color model. Exception: if
the "floating selection" belongs to a channel or layer mask, it will
be represented as grayscale pixels independently of the image's
overall color model.
Each pixel of a layer also has an alpha component which specifies the
opacity of the pixel on a linear scale from 0 (denoting an alpha of
0.0, or completely transparent) to 255 (denoting an alpha of 1.0, or
completely opaque). The color values do not use "premultiplied alpha"
storage. The color information for pixels with alpha 0 _may_ be
meaningful; GIMP preserves it when parts of a layer are erased and
provides (obscure) ways of recovering it in its user interface.
The bottommost layer _only_ in an image may not contain alpha Color
information; in this case all pixels in the layer have an alpha value -----
of 255. (Even if the bottommost layer does not cover the entire
canvas, it is the only layer that can be without an explicit alpha
channel).
In images that use the indexed color model, GIMP does not support RGB:
partial transparency and interprets alpha values from 0 to 127 as Three intensity values for red, green, and blue additive color
fully transparent and values from 128 to 255 as fully opaque. This components, each on a scale from 0 to 255. The exact color space
behavior _may_ change in future versions of GIMP. is not specified. GIMP displays image data directly on PC
display hardware without any software correction, so in most
cases the intensity values should be considered nonlinear samples
that map to physical light intensities using a power function
with an exponent ("gamma") of about 2.5. (This is how PC hardware
commonly treat bit values in the video buffer, which incidentally
also has the property of making each 1/255th step about equally