Back to RasterLite2 doc index

# Introduction

RasterLite2 supports many alternative image codecs, each one presenting its own specific characteristics. A good comprehension of the basic features offered by each codec will surely help you in using RasterLite2 at its best.The following simply is a very quick presentation mainly focused on practical aspects; if you are anyway interested in getting more rigorous and scientific informations you can easily found many exhaustive explanations by searching the Web.

#### Codec families

- the simplest codec you can imagine is
**NONE**: all pixels are directly stored exactly as they are without applying any compression.

This approach will obviously require an higher storage amount than any other method, but will surely ensure two positive results:- fast and very effective processing, due to the absolute absence of any extra overhead imposed by compressing algorithms.
- absence of any possible artifact; all pixels will be always preserved exactly as they are.

- a more sophisticated approach is the one supported by all compressors of the
**lossless**type:- any
**lossless**compressor is theoretically required to apply a perfectly reversible transformation.

i.e. after performing a fullcycle the original input values must be exactly restored without any information loss or alteration.*compress/decompress* - some interesting reduction of the required storage amount is always ensured.

Typically you can expect an ideal compression ratio of about**1:2**(i.e. half of the original uncompressed size), however you have to take this value with a pinch of salt.

The actual compression ratio will always depend both on the internal statistical distribution of pixel values and on the adopted algorithm; be ready to face a wide range of variability. - different compression algorithm have different performances, both in terms of compression ratio and in terms of processing time.

as a general rule any compression algorithm ensuring a stronger compression will require a longer time to be computed.

- any
- and finally we have several compressors of the
**lossy**type:- any
**lossy**compression will always imply some kind of irreversible information loss.

After performing a fullcycle you'll never get the original pixels, you'll get instead a more or less severely*compress/decompress***degraded**image. compressors are smartly designed accordingly to the average capabilities of the human eye.*lossy*

The degraded image returned by a good qualitycompressor will apparently look exactly the same of the original one to an human observer.*lossy*

Anyway a most rigorous computational approach will certainly detect that many pixels have irreversibly changed their values.- all compressors of the
type support variable (and freely selectable) compression ratios:*lossy*- very strong compression ratios will always introduce a severe image degradation.
- bland compression ratios will introduce only a moderate image degradation.

- all
compressors are always expected to ensure very strong compression ratios; surely better than the ones expected by*lossy*compressors.*lossless* - also in the case of
compressors different algorithms have different performances. Some codecs are incredibly fast, others are really slow.*lossy*

- any

Lossless codecs |
---|

### the **DEFLATE** codec

Jack of all trades, master of none,Certainly better than a master of one. |

This codec is based on the same algorithm used by the very popular

**zip**and

**gzip**compression utilities. The RasterLite2 own implementation always applies a

**Delta Filter**so to ensure an optimal compression ratio:

- Pixel values are never directly encoded as they are but as
(*differences**aka*) between consecutive pixels pairs. The opposite transformation will be applied while decompressing.*deltas* - This way the internal statistical variance will be noticeably flattened, and this will usually ensure a more effective compression.

(*the same identical technique is usually referenced in***TIFF**and**GDAL**documentation as**predictor=2**).

**PROS**- it's very flexible: it supports all possible combinations of Sample and Pixel type.
- it's very fast: it's actually the fastest of all
compressors.*lossless*

It imposes a very bland compression overhead, and it has an incredibly low impact while decompressing.

**CONS**- in pure compression ratio terms many other
compressors could easily outperform*lossless***DEFLATE**.

- in pure compression ratio terms many other

### the **DEFLATE_NO** codec

Exactly the same as **DEFLATE**except in that it never applies a

**Delta Filter**.

### the **PNG** codec

This codec is based on the popular **PNG**image format and is fully based on DEFLATE supported by several filters explicitly intended for images.

**PROS**- it's reasonably flexible: it supports many combinations of Sample and Pixel type (including MONOCHROME and PALETTE).

**CONS**- it's unable to support 32 bit and FLOAT/DOUBLE samples, and it's restricted to 1, 3 or 4 bands.

**REMARKS**- compression ratios are usually very close to the ones achieved by DEFLATE: sometimes DEFLATE performs better than PNG, other times it's the opposite.

Anyway PNG constantly has worst performances than DEFLATE in pure speed terms.

- compression ratios are usually very close to the ones achieved by DEFLATE: sometimes DEFLATE performs better than PNG, other times it's the opposite.

### the **LZMA** codec

This codec is based on the same algorithm used by the very popular **7-zip**compression utility. The RasterLite2 own implementation always applies a

**Delta Filter**so to ensure an optimal compression ratio (exactly the same adopted by DEFLATE).

**PROS**- it's very flexible: it supports all possible combinations of Sample and Pixel type.
- it always ensures higher compression ratios than DEFLATE.

Anyway the difference isn't a so striking one in many common cases.

**CONS**- it's painfully slow.
It's about
**4-5 times**slower than DEFLATE while compressing; and it's about**2 times**slower while decompressing.

- it's painfully slow.
It's about

### the **LZMA_NO** codec

Exactly the same as **LZMA**except in that it never applies a

**Delta Filter**.

### the **FAX4** codec

This codec is based on an ultra-specialized compressor originally designed for **FAX machines**and only supporting

**1-bit MONOCHROME**pixels.

**PROS**- it's really fast.
- it always ensures higher compression ratios than PNG (the unique alternative codec accepting 1-bit pixels).

**CONS**- not at all flexible; it's strictly intended for 1-bit images.

### the **LL_WEBP** codec

This codec is based on the **lossless**flavor of the

**WebP**compressor.

**PROS**- in pure terms of compression ratios seems to be the most powerful lossless compressor available today.

**CONS**- it has a very limited field of application; only 1, 3 or 4 bands UINT8 samples are supported.
- it's painfully slow. I intend more exactly deadly slow ... a real slowcoach.

It's terribly slow while compressing; it shows better performances while decompressing, but it still remains one the worst performers in speed terms.

### the **LL_JP2** codec

This codec is based on the **lossless**flavor of the

**Jpeg2000**compressor as implemented by the

**OpenJpeg**open source library.

**Caveat**: the OpenJpeg library has a very long development history (about 10 year long), but only in very recent times has finally become practically usable.

Earlier versions were bug ridden, terribly slow and not at all usable. Using the very recent versions

**2.0**or

**2.1**is a strict requisite.

**PROS**- it's reasonably flexible: it supports 1, 3 or 4 bands, and it accepts bot UINT8 and UINT16 samples.

**CONS**- not completely flexible; there are many unsupported Sample / Pixel combinations.
- it's painfully slow. Even worst than WebP if possible.

It's terribly slow while compressing, more or less as WebP is; but differently from WebP it's terribly slow even while decompressing. - its compression ratios are usual interesting, but it's regularly outperformed by some other compressor.
- last but not least: it's not genuinely
**lossless**.

## Caveat: Jpeg2000 lossless isn't exactly lossless !!!I've set up a basically simple testbed:- I've created several RasterLite2 Coverages into the same DB-file, each one based on a different lossless codec.
Except for this all Coverages were created by applying the same identical settings. - then I've populated all these Coverages by inserting exactly the same dataset in all them.
- finally I've used a very simple C program performing the following actions:
- reading and decoding all tiles from the Coverage adopting the NONE compression.
- reading and decoding all tiles from another Coverage adopting one of the available lossless compressions.
- compare one by one all corresponding pixels from the NONE tile and from the lossless compressed tile reporting any discrepancy found.
- perform yet again the same loop on every Coverage adopting some lossless compression.
**DEFLATE**,**PNG**and**LZMA**are effectively lossless, i.e. there is no discrepancy at all when comparing corresponding pixels from the NONE Coverage. This is not at all surprising, and simply is a practical confirmation of standard expectations.**WEBP**too is effectively lossless. This was a not so obvious result and surely is a welcome objective confirmation.- unhappily the
**Jpeg2000 / OpenJpeg**compression reveals to be almost lossless but not perfectly lossless. There are very few pixels changing their value by exactly 1 unit (sometimes in excess, other times in defect). So the decompressed image isn't exactly the same of the original one, and this forbids to consider this codec as perfectly lossless. I personally ignore if this one is a bug in the OpenJpeg implementation or is a defect in the Jpeg2000 design; anyway it surely is a potentially dangerous issue.
Conclusion: never use the Jpeg2000 lossless codec if one of your strict requirements is to be absolutely sure to get back exactly the original input data. |

Lossy codecs |
---|

### the **JPEG** codec

This codec is based on the very popular **JPEG**image format.

**PROS**- in terms of pure speed it's the fastest lossy compressor available today.

It's so fast that it actually outperforms the NONE codec due a very favourable trade-off between I/O sizes and computational load. - at moderate compression ratios (anyway ensuring a noticeable compression) it offers a very good visual quality.

- in terms of pure speed it's the fastest lossy compressor available today.
**CONS**- it has a very limited field of application; only 1 or 3 bands UINT8 samples are supported.
- at the highest compression ratios it visibly suffers from conspicuous and annoying artifacts. Both WebP and Jpeg2000 are better in this very specific field.

### the **WEBP** codec

This codec is based on the **lossy**flavor of the

**WebP**compressor.

**PROS**- it supports a better visual quality than JPEG at highest compression ratios.
- at moderate compression ratios it requires a smaller storage amount than JPEG.

**CONS**- it has a limited field of application; only 1, 3 or 4 bands UINT8 samples are supported.
- It's really slow while compressing and it surely hasn't brilliant performances while decompressing.

### the **JP2** codec

This codec is based on the **lossy**flavor of the

**Jpeg2000**compressor.

**PROS**- it supports a better visual quality than JPEG at highest compression ratios.
- at moderate compression ratios it requires a smaller storage amount than JPEG.
- it has a fairly good field of application; 1, 3 or 4 bands for both UINT8 and UINT16 samples are supported.

**CONS**- It's really slow while compressing and it's terribly slow even while decompressing.

Conclusions |
---|

### lossless codecs

**DEFLATE**always is a valid option: it offers fairly good compression ratios (never excellent anyway) but it's really fast.

It can be applied to many different Pixel / Sample types; certainly an honest although unsophisticated multipurpose compressor.**PNG**is more or less the same of DEFLATE (slightly slower): anyway it's the unique codec supporting pixels of the PALETTE type.**FAX4**is an excellent specialized compressor supporting only 1-bit samples.**LZMA**has exactly the same field of applicability than DEFLATE; it always offers higher compression ratios but at the cost of imposing longer processing timings.- both the
**DEFLATE_NO**and**LZMA_NO**codecs are mainly intended for research/testing purposes, and are never expected to reach interesting compression ratios (except may be with few extravagant dataset presenting some bizarre pixel distribution). **LL_WEBP**usually offers very good compression ratios, but it only supports a very limited range of Pixel / Sample combinations.

It always imposes poor performances; to be very judiciously applied only in very specific cases.**LL_JP2**only has disadvantages: it seems unable to offer very good compression ratios, and it's deadly slow. Last but not least, it's only imperfectly lossless.

### lossy codecs

**JPEG**is the most obvious best choice in many cases.

It's astonishingly fast (most notably in its**turbo-Jpeg**implementation) and it supports a very good visual quality except than at the most extreme compression ratios.**WEBP**doesn't seems to be really interesting if not at highest compression ratios. Its painful slowness is a severe handicap.- more or less the same if for
**JPEG2000**; its terrible slowness obliterates any possible interesting feature.

Anyway Jpeg2000 could eventually be an interesting option in the case of UINT16 samples.

Back to RasterLite2 doc index