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. 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.
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? If we can't extend Tight encoding, then my counter-proposal would be to create a new rfbEncodingTightNoZlib method. _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
