?? qtbpc.html
字號(hào):
<HTML><HEAD><TITLE>Qbit Details</TITLE></HEAD><BODY><CENTER><h1>Quad Tree Bit Plane Compression</h1></CENTER><h3>File Format</h3>The data stream consists of two segments, a series of half bytes (quads) at the end of the file, and a run of 16 bit masks at the start. The quads are a data stream that represent uniform bit planes within the image encoded in a quad tree structure. Every node in the tree is a run of <i>n</i> bytes.Each of these bytes represents a bit plane for the four interior nodes, two bits per node. The four least significant bits are control bits, one for each interior quadrant, and other four are considered state bits.<p>If an interior node has it's control bit set, this means that for this bit plane, all the pixels within the quadrant contain uniform coverage. The "state" bit then represents that coverage. No more information is encoded for this bit, within the current node, in the data stream.<p>A full byte is only read if the corresponsing state bit of the parent is set. If not then a half byte is read from the stream and considered to be the 4 most significant bits<p>The parent node of the terminating leaf node does not write any statebits of no block bits are in the stream.<p>The tree resolves at pixel blocks measuring 4 by 4. Bit planes within this block that are not unique are written out as 16 bit masks at the start if the file.<p>The encoder looks at each image virtually as if it were a square with dimentions equal to the lowest power of two that will contain it. The superflous area outside the image is considered to be what will yeild the best results when encoding, and is ignored when decoding.<p>This alone produces varying degress of compression depending on the image. A solid block of colour compresses to the file header + <i>bitdepth</i> bytes. Images with entire ranges of colours absent, or RGB images with large patches of blue, red etc... compress well. Noisy images show little gain.<p><h3>Palette Blocks</h3>A preprocess that reduces the overall bitrate of pixels within a quadrant is optional;y run on the whole image, and every other second level starting at the quadrant 16 * 16 and up until the second level below the initial virtual square image. The palette renumbers the colours but doesn't change the numerical order, therefor it only has to encode the difference between one included colour and the next. Initially the bytes of the image are reordered by byte order and significance. For example, a 24 bit image will contain the most significant bit from the three colour components in the three most significant bits.<p>These "spans" are encoded using a rolling register system that writes out 4 bits at a time signifying the inclusion of all possibilities of every two bits in the colour stream. This could probably be improved with a static huffman tree or somehting similar, at the expense of processing speed<p>When within the image, the palette writes out one control half byte specying it's bounds. This can be 15 to signify that the quadrant at this level is not paletted. The compressor can use any logic it likes to determine this including good old fashioned "try every combination" trial and error. This is unlikely to produce any significant imrpovement over simply avoiding this step for a quadrant and it's sub-quadrant if it's colour count is too high, or the same as it's parent quasdrant.<p><p></BODY></HTML></BODY></HTML>?? 快捷鍵說(shuō)明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號(hào)
Ctrl + =
減小字號(hào)
Ctrl + -