Sun rasterfile: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
(Change description link (Reason: Link DEAD))
(Add Sunrast Description and Sunrast RLE explanation)
Line 6: Line 6:
Sun rasterfile is an image file format supporting images of depth 1, 4, 8 (with palette) , 24 and 32 bits in either raw format or compressed with (yet again) a custom [[RLE]] scheme.
Sun rasterfile is an image file format supporting images of depth 1, 4, 8 (with palette) , 24 and 32 bits in either raw format or compressed with (yet again) a custom [[RLE]] scheme.
The file format was developed by Sun during the eighties.
The file format was developed by Sun during the eighties.
__TOC__


== The Header ==
The sunrast header consists of 32 (8 * 4) bytes with the following attributes:
# SUNRAST magic number (i.e 0x59a66a95)
# Image Width
# Image Height
# Depth (bits per pixel)
# length (length of image data [in bytes])
# Type (Type of encoding i.e RAW or RLE)
# Maptype (Type of Colourmap , RGB in 8bpp and None in others)
# Maplength (Length (in bytes) of the colourmap used)
== The Palette Data ==
The format follows a planar structure for the palette data. (i.e RRR.. GGG.. BBB.. instead of RGB RGB ...).
== Image Data ==
The format has 2 types of Image Data, RAW and Run Length Encoded.
=== Run Length Encoding ===
The format implements a version of Run Length Encoding to encode pixels. The byte value 0x80 is a trigger to read a runlength for the next value, otherwise bytes are written as-is. A stream value of 0x80 must be handled as a special-case (explained below) since that value is also used as the runlength trigger.
A basic Sunrast RLE encoded stream would look like :-
[0x80] [runlength – 1] [value]
example :-
[0x01 0x01 0x01] would be encoded to [0x80 0x02 0x01]
Explanation :-<br />
0x80 indicates the start of run length encoded bits (RLE trigger).<br />
0x03 indicates the runlength (run – 1).<br />
0x01 indicates the value to be repeated.<br />
<br />
but, the format also handles some special cases which are explained below :-<br />
[0x01 0x02 0x03] would stay the same in the encoded file.
Explanation :-<br />
As in above bytes the runlength is 1 for each byte the sunrast algorithm does not employ RLE on such bytes , so as to avoid increase in the number of bits used. <br />
<br />
[0x80 0x01 0x02] would be encoded to [0x80 0x00 0x01 0x02]
Explanation :-<br />
0x80 0x00 , This set indicates that the value is same as RLE trigger and without RLE.<br />
0x01 0x02 , These indicates the next set of values (without RLE).<br />
<br />
[0x80 0x80 0x80] would be encoded to [0x80 0x02 0x80]
Explanation :-<br />
0x80 indicates the start of run length encoded bits (RLE trigger).<br />
0x02 indicates the runlength (run – 1).<br />
0x80 indicates the value to be repeated.<br />
== Tests ==
Aneesh Dogra (lionaneesh) from libav carried out some tests to check the effectiveness of the Sunrast's RLE algorithm.
* For most of the real images (rgb24) the algorithm turned out to be a little expensive. RLE encoding was actually costing more bytes (aproximately 0.2% – 0.3% more) instead of RAW encoding. This could have only happened because of greater instances of 0x80 byte (and that too non continuous) for an explanation how it can cost more bytes (see example [2])
* For Artificial images the algorithm seems more suitable and turns out to be quite beneficial, in some images with lots of white-space or uniform colour RLE encoding was saving more than 50% - 60% bytes which seems quite a lot.
[[Category:Image Formats]]
[[Category:Image Formats]]

Revision as of 00:53, 17 February 2012

Sun rasterfile is an image file format supporting images of depth 1, 4, 8 (with palette) , 24 and 32 bits in either raw format or compressed with (yet again) a custom RLE scheme. The file format was developed by Sun during the eighties.

The Header

The sunrast header consists of 32 (8 * 4) bytes with the following attributes:

  1. SUNRAST magic number (i.e 0x59a66a95)
  2. Image Width
  3. Image Height
  4. Depth (bits per pixel)
  5. length (length of image data [in bytes])
  6. Type (Type of encoding i.e RAW or RLE)
  7. Maptype (Type of Colourmap , RGB in 8bpp and None in others)
  8. Maplength (Length (in bytes) of the colourmap used)

The Palette Data

The format follows a planar structure for the palette data. (i.e RRR.. GGG.. BBB.. instead of RGB RGB ...).

Image Data

The format has 2 types of Image Data, RAW and Run Length Encoded.

Run Length Encoding

The format implements a version of Run Length Encoding to encode pixels. The byte value 0x80 is a trigger to read a runlength for the next value, otherwise bytes are written as-is. A stream value of 0x80 must be handled as a special-case (explained below) since that value is also used as the runlength trigger.

A basic Sunrast RLE encoded stream would look like :-

[0x80] [runlength – 1] [value]

example :-

[0x01 0x01 0x01] would be encoded to [0x80 0x02 0x01]

Explanation :-
0x80 indicates the start of run length encoded bits (RLE trigger).
0x03 indicates the runlength (run – 1).
0x01 indicates the value to be repeated.

but, the format also handles some special cases which are explained below :-

[0x01 0x02 0x03] would stay the same in the encoded file.

Explanation :-
As in above bytes the runlength is 1 for each byte the sunrast algorithm does not employ RLE on such bytes , so as to avoid increase in the number of bits used.

[0x80 0x01 0x02] would be encoded to [0x80 0x00 0x01 0x02]

Explanation :-
0x80 0x00 , This set indicates that the value is same as RLE trigger and without RLE.
0x01 0x02 , These indicates the next set of values (without RLE).

[0x80 0x80 0x80] would be encoded to [0x80 0x02 0x80]

Explanation :-
0x80 indicates the start of run length encoded bits (RLE trigger).
0x02 indicates the runlength (run – 1).
0x80 indicates the value to be repeated.

Tests

Aneesh Dogra (lionaneesh) from libav carried out some tests to check the effectiveness of the Sunrast's RLE algorithm.

  • For most of the real images (rgb24) the algorithm turned out to be a little expensive. RLE encoding was actually costing more bytes (aproximately 0.2% – 0.3% more) instead of RAW encoding. This could have only happened because of greater instances of 0x80 byte (and that too non continuous) for an explanation how it can cost more bytes (see example [2])
  • For Artificial images the algorithm seems more suitable and turns out to be quite beneficial, in some images with lots of white-space or uniform colour RLE encoding was saving more than 50% - 60% bytes which seems quite a lot.