Add TightPNG encoding

[sidorares]

http://wiki.qemu.org/VNC_Tight_PNG

[vtolstov]

i think this is more proper place. Now i need only working compact length calculation for tight png working.
I found simple code from wireshark dissector for tight encoding
http://code.metager.de/source/xref/wireshark/epan/dissectors/packet-vnc.c#3031

i'm already check my own code and it looks the same. So i'm stuck now.
sorry for reindent issues =( . i'm cleanup pr when it will be ready
https://github.com/sidorares/node-rfb2/compare/master...vtolstov:master?expand=1

[vtolstov]

As i debug, png data in rectangle in my case started after
0,0,0,0,0,0,19,0,231,0,13,255,255,254,252,160,224,2

first rect has rect.x 0 rect.y 0 rect.width 1024 rect.height 19

[sidorares]

I'll be able to help early tomorrow ( +9 hours in my time)

[vtolstov]

No problem, now i have free time and may be found some own mistakes

[vtolstov]

@sidorares so i think that we have error in decoding stream.
In case of raw encoding, do you have proper image received from frame buffer update message?

[sidorares]

what I see is that first byte is 0 and reading stops because it's not tight.png

        var tight = rfb.subEncodings.tight;
        console.log('TIGHT: byte 0', ctl[0]);
        ctl = ctl[0] >> 4;
        if (ctl & tight.png) {
            console.log('Reading tight png...');
            cli.readTightPng(rect, cb);
        }

[vtolstov]

Does it possible this issue with endianes? or all rectangles and encoding always send via little endian?

[sidorares]

no, I think the issue is that we can't just add png part only. We need to decode BasicCompression bytes ( or at leas skip them ) - see BasicCompression part here - https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#id78

[vtolstov]

But basic compression part goes after control part...

[vtolstov]

And we have control = 0...

[sidorares]

When I connect first update seems to be in tight / BasicCompression - same color rectangle, I think control byte is followed by single TPIXEL value ( I guess it 3 bytes )

The Tight encoding makes use of a new type TPIXEL (Tight pixel). This is the same as a PIXEL for the agreed pixel format, except where true-colour-flag is non-zero, bits-per-pixel is 32, depth is 24 and all of the bits making up the red, green and blue intensities are exactly 8 bits wide. In this case a TPIXEL is only 3 bytes long, where the first byte is the red component, the second byte is the green component, and the third byte is the blue component of the pixel color value.

[sidorares]

But basic compression part goes after control part...

isn't control = 0 indication of basic compression?

[vtolstov]

@sidorares yes, but why we have tpixel?

[sidorares]

as far as I understand, basic compression + fill = one single pixel follows, same color for whole rectangle

[vtolstov]

so i need to add to tight some compression types like fill, jpeg, basic compression types and recheck control for it ?