On Thu, 11 Jun 2009 13:30:41 +0200 Peter Rosin <p...@lysator.liu.se> wrote:
> +The least significant four bits of *compression-control* byte inform > +the client which zlib compression streams should be reset before > +decoding the rectangle. Each bit is independent and corresponds to a > +separate zlib stream that should be reset: > + > +================== ==================================================== > +Bit Description > +================== ==================================================== > +0 if 1: reset stream 0 > +1 if 1: reset stream 1 > +2 if 1: reset stream 2 > +3 if 1: reset stream 3 > +================== ==================================================== I think the "if 1:" part is implied. :) > +One of three possible compression methods are supported in the Tight > +encoding. These are **BasicCompression**, **FillCompression** and > +**JpegCompression**. If the bit 7 (the most significant bit) of > +*compression-control* byte is 0, then the compression type is > +**BasicCompression**. In that case, bits 7-4 (the most significant four > +bits) of *compression-control* should be interpreted as follows: > + > +=============== =================== =================================== > +Bits Binary value Description > +=============== =================== =================================== > +5-4 00 *UseStream0* > +.. 01 *UseStream1* > +.. 10 *UseStream2* > +.. 11 *UseStream3* > +6 0 --- > +.. 1 *ReadFilterId* > +7 0 **BasicCompression** > +=============== =================== =================================== > + ReadFilterId is never explained. And the rest of the document uses lower case and dashes for keywords. > +Otherwise, if the bit 7 of *compression-control* is set to 1, then the > +compression method is either **FillCompression** or > +**JpegCompression**, depending on other bits of the same byte: > + > +=============== =================== =================================== > +Bits Binary value Description > +=============== =================== =================================== > +7-4 1000 **FillCompression** > +.. 1001 **JpegCompression** > +.. any other invalid > +=============== =================== =================================== > + > +Note: **JpegCompression** may only be used when *bits-per-pixel* is > +either 16 or 32. Is this really a requirement, or just how the servers are implemented? I.e. will the clients cope with that method when bpp is 8? We should also mention that the server must not use JPEG when no quality level has been selected. (I know this is mentioned in your next patch, but it should be pointed out here as well for clarity) > +**FillCompression** > + > + If the compression type is "fill", then the only pixel value > + follows, in client pixel format (see [NOTE1]_). This value applies > + to all pixels of the rectangle. These tight specific pixels are used everywhere. Perhaps they should be mentioned early, like CPIXEL for ZRLE? And when you mention "fill" like that, it seems like you're referring to some canonical name. I suggest to just leave those kinds of short names out and just the **FillCompression** type of names. > +**JpegCompression** > + > + If the compression type is "jpeg", the following data stream looks > + like this: > + > + =============== =================== =============================== > + No. of bytes Type Description > + =============== =================== =============================== > + 1-3 *length* in compact > + representation > + *length* ``U8`` array *jpegData* > + =============== =================== =============================== > + > + *length* is compactly represented in one, two or three bytes, > + according to the following scheme: > + > + =========================== ======================================= > + Value Description > + =========================== ======================================= > + 0xxxxxxx for values 0..127 > + 1xxxxxxx 0yyyyyyy for values 128..16383 > + 1xxxxxxx 1yyyyyyy zzzzzzzz for values 16384..4194303 > + =========================== ======================================= > + > + Here each character denotes one bit, xxxxxxx are the least > + significant 7 bits of the value (bits 0-6), yyyyyyy are bits 7-13, > + and zzzzzzzz are the most significant 8 bits (bits 14-21). For > + example, decimal value 10000 should be represented as two bytes: > + binary 10010000 01001110, or hexadecimal 90 4E. > + I suspect the Tight project never properly specified this, but what restrictions are placed on the JPEG data? We should at the very least mention that it is a standard JFIF data stream. And if we cannot properly specify the JPEG restrictions, we should mention that the area is a bit grey. > +.. [NOTE3] The "gradient" filter and "jpeg" compression may be used > + only when bits-per-pixel value is either 16 or 32, not 8. Again, is this a hard requirement? > + > +.. [NOTE4] The width of any Tight-encoded rectangle cannot exceed > + 2048 pixels. If a rectangle is wider, it must be split into several > + rectangles and each one should be encoded separately. Dito. Also, using footnotes without any reference in the text seems wrong. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
_______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
