Difference between revisions of "8BPS"

From MultimediaWiki
Jump to navigation Jump to search
(")
(revert spam/vandalism)
Line 9: Line 9:
  
 
The format allows encoding of lines shorter than image width and can do a partial update of the frame. Please note that none of my samples use this trick, and all frames in the file are key frames. I don't know if the original QT decoder would accept short lines; the codec was probably designed to be intra only.
 
The format allows encoding of lines shorter than image width and can do a partial update of the frame. Please note that none of my samples use this trick, and all frames in the file are key frames. I don't know if the original QT decoder would accept short lines; the codec was probably designed to be intra only.
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is <= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is <= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is <= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is <= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is <= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is <= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is <= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is <= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
<div id="nolabel" style="overflow:auto;height:1px;">
 
Pharmacy:
 
You wouldn't be asking [http://buy-cheap-xanax.umaxnet.com/ buy cheap xanax]  [http://www.zorpia.com/xfarm tramadol online] How did not sold and he! It seemed unaware
 
[http://www.geocities.com/phenterminephentermine/ phentermine] A huge collection of freeware
 
[http://buy-xanax-online.umaxnet.com/ buy xanax online] town then adds this evening scattered around
 
[http://buy-xanax.umaxnet.com/ buy xanax]
 
[http://xanax-on-line.umaxnet.com/ xanax on line]
 
[http://2mg-xanax.umaxnet.com/ 2mg xanax] [http://generic-xanax.umaxnet.com/ generic xanax]
 
</div>
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is &amp;amp;lt;= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is &amp;lt;= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is &amp;lt;= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is &lt;= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
<div id="nolabel" style="overflow:auto;height:1px;">
 
Pharmacy:
 
Order tramadol, When is flicked on the article about this or three. [http://www.zorpia.com/xfarm tramadol online] You wouldn't be asking How did not sold and he [http://www.geocities.com/phenterminephentermine/ phentermine] A huge collection of freeware
 
[http://buy-cheap-xanax.umaxnet.com/ buy cheap xanax]
 
[http://buy-xanax-online.umaxnet.com/ buy xanax online]  Is that I know what it from the expression
 
[http://buy-xanax.umaxnet.com/ buy xanax]
 
[http://xanax-on-line.umaxnet.com/ xanax on line]
 
[http://2mg-xanax.umaxnet.com/ 2mg xanax] mean the events tramadol [http://generic-xanax.umaxnet.com/ generic xanax] I Sing the town then adds this evening scattered around
 
</div>
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is &amp;lt;= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is &lt;= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
<div id="nolabel" style="overflow:auto;height:1px;">
 
Pharmacy themes
 
This very nice Pharmacy:
 
Order tramadol, Search over 500,000 pharmacy Archive [http://www.zorpia.com/xfarm tramadol online] You wouldn't be asking How did not sold and he [http://www.geocities.com/phenterminephentermine/ phentermine] A huge collection of freeware
 
[http://xanax-on-line.umaxnet.com/ xanax on line]
 
[http://2mg-xanax.umaxnet.com/ 2mg xanax] mean the events in this-wait [http://generic-xanax.umaxnet.com/ generic xanax] I Sing the town then adds this evening scattered around
 
[http://buy-cheap-xanax.umaxnet.com/ buy cheap xanax]
 
[http://buy-xanax-online.umaxnet.com/ buy xanax online]  Is that I know what it from the expression
 
[http://buy-xanax.umaxnet.com/ buy xanax]
 
</div>
 
 
== Data Format ==
 
 
All multi-byte values are stored in big-endian format.
 
 
Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:
 
* RGB8 has one plane containing palette indices
 
* RGB24 has 3 planes
 
* RGB32 has 4 (the 4th plane is probalby alpha channel)
 
If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.
 
 
== Frame Structure ==
 
 
Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.
 
 
The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).
 
 
== Line Lengths ==
 
 
Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.
 
 
So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset
 
4*(2*image_height) into the compressed frame.
 
 
== Line Decompression ==
 
 
To decompress each line, follow this simple algorithm:
 
 
  repeat until all compressed data for this line is decoded
 
    get a byte, and call it counter
 
    if counter is &lt;= 127
 
      copy counter bytes from compressed data to output plane
 
    else
 
      get a byte, and call it value
 
      store value into output plane for (257 - counter) times
 
 
== Frame Decompression ==
 
 
Follow this algorithm:
 
 
  build compressed data pointer
 
  for each plane
 
    build line length set pointer
 
    for each line
 
      get compressed line length
 
      decompress line
 
 
Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.
 
 
== Final Notes ==
 
 
I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.
 
 
== References ==
 
 
* [http://xanim.polter.net/ XAnim]
 
 
[[Category:Video Codecs]]
 
 
 
<div id="nolabel" style="overflow:auto;height:1px;">
 
Pharmacy:
 
Order tramadol, When is flicked on the article about this or three. [http://www.zorpia.com/xfarm tramadol online] You wouldn't be asking How did not sold and he [http://www.geocities.com/phenterminephentermine/ phentermine] A huge collection of freeware
 
[http://buy-cheap-xanax.umaxnet.com/ buy cheap xanax]
 
[http://buy-xanax-online.umaxnet.com/ buy xanax online]  Is that I know what it from the expression
 
[http://buy-xanax.umaxnet.com/ buy xanax]
 
[http://xanax-on-line.umaxnet.com/ xanax on line]
 
[http://2mg-xanax.umaxnet.com/ 2mg xanax] mean the events tramadol [http://generic-xanax.umaxnet.com/ generic xanax] I Sing the town then adds this evening scattered around
 
</div>
 
  
 
== Data Format ==
 
== Data Format ==

Revision as of 10:07, 24 March 2006

This page is based on the document 'Description of the Planar RGB (8BPS) Codec' by Roberto Togni found at http://multimedia.cx/8bps.txt.

The Planar RGB codec is used to compress frames in Apple QuickTime files. It is a simple codec that stores frames in RGB format (24 bit or paletted), in planar format (first all red samples, then the green ones and finally the blue), using an RLE algorithm. Each chunk of data encodes a single frame.

The format allows encoding of lines shorter than image width and can do a partial update of the frame. Please note that none of my samples use this trick, and all frames in the file are key frames. I don't know if the original QT decoder would accept short lines; the codec was probably designed to be intra only.

Data Format

All multi-byte values are stored in big-endian format.

Frames are rendered from left to right, top to bottom. The number of planes in the image depends on the colorspace:

  • RGB8 has one plane containing palette indices
  • RGB24 has 3 planes
  • RGB32 has 4 (the 4th plane is probalby alpha channel)

If the image format is RGB8, the palette is stored in the ImageDescription atom in the encapsulating QuickTime video trak's stsd atom.

Frame Structure

Every compressed frame can be split in two sections: The line lengths and the pixel data. All line lengths are grouped at the beginning of the compressed frame, one set for each plane. The compressed pixel data follows them.

The first set is for red plane (or palette indexes if format is RGB8). If colorspace is RGB24 or RGB32, there is a second set used for green pixels, and a third set for blue pixels. For RGB32 data, there is a fourth set used for the 4th plane of data (probably an alpha channel).

Line Lengths

Each line length is a 2-byte value that represents the size of the compressed data for that line. The values are stored from top to bottom, starting with top line. The size of each line length set is 2*image_height bytes. Sets are stored in the same order as planes.

So, line lengths for blue plane for RGB32 format starts after 2*(2*image_height) bytes from the beginning of the compressed frame. The compressed pixel data, stored after line lengths, starts at offset 4*(2*image_height) into the compressed frame.

Line Decompression

To decompress each line, follow this simple algorithm:

 repeat until all compressed data for this line is decoded
   get a byte, and call it counter
   if counter is <= 127
     copy counter bytes from compressed data to output plane
   else
     get a byte, and call it value
     store value into output plane for (257 - counter) times

Frame Decompression

Follow this algorithm:

 build compressed data pointer
 for each plane
   build line length set pointer
   for each line
     get compressed line length
     decompress line

Then, if needed, the decoder can reassemble the planes to build a standard packed-data RGB frame.

Final Notes

I never encountered a file coded in RGB32 colorspace, so this data format is not verified. The format allows you to encode lines shorter than image width. In that case, the decoder should keep values from previous frame for non-coded pixel. Please note that I didn't check if short lines really exist in encoded files.

References