Indexed colorspaces are a very useful way of reducing the amount of memory and space needed when they only have a certain number of repeating colour values. You define a limited set number of colour values (usually 2,4, 16 or 256) and define a color value for each. The image is then defined in terms of which colour value is used, not the actual color. This is much more compact in memory usage. It is best explained by an example.
Let’s image you have a image in CMYK colour. That means you need 4 bytes to describe the colour of each pixel. If the image had 4,000 pixels, that would be 16,000 bytes.
Now, imagine that the image only used 255 different colors. Instead of storing each pixel value, we could have a table with 256 entries (that is 1,024 bytes storing the 4 bytes for each CMYK color used) and then just store 1 byte per pixel to say which entry in the table to use. That would be a total of 4,000 bytes (for the colours) and 1,024 bytes for the look-up table. That is 5,024 bytes (quite a reduction from the 16,000 bytes.
And if we do not need 256 colours, we could do even better by squashing the bits together. If we only had 2 colours, we would still need 8 bytes for the look-up table but only a bit (one eighth of a byte) for each pixel to say which colour to use – a total of 508 bytes for everything!
This is what an indexed colorspace does. It allows us to store a table of colours in a look-up table and store the index, not the color. This reduces substantially the size of data needed. It works best with fewer colours so images with a huge number of colours do not gain as well and could actually take up more memory. But for appropriate images, 16,000 bytes to 508 bytes is a substantial size reduction.
Are you a Developer working with PDF files?
|Free: The Developer's Guide to PDF|
|Convert PDF files to HTML|
|Use PDF Forms in a web browser|
|Convert PDF Documents to an image|
|Work with PDF Documents in Java|