On Wed, Sep 02, 2009 at 05:09:44PM -0500, DRC wrote: > Adam Tkac wrote: > > There is a bug report about creation of the separate JPEG encoding - > > http://sourceforge.net/tracker/?func=detail&aid=2674740&group_id=254363&atid=1126849. > > > > If we are really going to create new JPEG encoding and document it > > in the RFB protocol we should not create separate encoding for each > > quality level. We should include image quality control as part of the > > JPEG encoding. I know it will take more time than straightforward port > > from TurboVNC. What do you think about that? > > > These extensions are not necessarily specific to JPEG. They could be > used by other encoding methods that need fine-grained quality control.
Yeah, you are absolutely correct. But I'm not sure that all future encodings will use same image quality schema as JPEG. If we add new pseudo encodings to control the JPEG specific quality levels I think we polute "encoding namespace". > I'm not sure I understand what you're proposing. I understand the > notion of creating a separate rfbEncodingJpeg method, but why does that > preclude what I'm proposing above? We still need to define a way for > the client to request a fine-grained quality change from the server. > Please provide a specific example of how you would propose to do that. If I understand correctly you are proposing separate messages (with "messages" I mean multiple rectangles with different encodings) for JPEG and quality levels. Communication client<->server will look like: client->server JPEG encoding is supported server->client Framebuffer update encoded in JPEG client->server Change quality to level X With this approach you pollute "encodings namespace" with 100 new encodings which should be bound to the JPEG encoding. I propose different approach. JPEG client->server message will include information about quality level. Main difference with my and your proposals is that you've added 100 new encodings but I've added only one JPEG encoding. > What I'm proposing is very similar to how rfbEncodingCompressLevelX > works currently. The client can request a specific compress level or > quality level in addition to specifying the encoding method. > > > Unfortunately I don't think we can extend the Tight encoding. You > > should discuss this change with Constantin. > > > I'm not sure I understand how this works. Can someone enlighten me as > to how RFB extensions are registered and conflicts are avoided? If > there is no official registry for RFB extensions, then why am I > bothering to go through this process? Well, the place is probably here and also on https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto. > If we can't extend Tight encoding, then my counter-proposal would be to > create a new rfbEncodingTightNoZlib method. The Tight encoding is tricky. It is `owned` by Constantin Kaplinsky and the TightVNC project. I think we should not touch it unless Constantin approves the change. Btw could I ask you why would you like to create such encoding? Regards, Adam -- Adam Tkac, Red Hat, Inc. _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
