You can read my comments on the issue in the libjpeg-turbo bug report you linked to below, but I'll add some further clarifying remarks:
-- The libjpeg API is very old at this point. The first release of libjpeg was 25 years ago, and the jpeg-6b API that most projects use is nearly 20 years old. Thus, it has a lot of what I call "canonical quirks"-- behaviors that are arguably incorrect, but they've existed in the API for so long that changing them could actually break certain applications. This issue is a good example of that. -- Pierre's position was that this behavior on the part of libjpeg-turbo was incorrect. My position was that this behavior is a canonical quirk in the libjpeg API. The behavior also exists in all releases of libjpeg (at least since jpeg-6b), so if we change it in libjpeg-turbo, we are technically introducing an incompatibility. -- This issue never existed in the TurboVNC Server, because TurboVNC uses the higher-level TurboJPEG API, not the lower-level libjpeg API. That is, TurboVNC does full-image JPEG compression and decompression rather than using buffered compression/decompression like TigerVNC does. Switching to the TurboVNC Server will definitely make this go away. -- The issue is probably difficult (but I suspect not impossible) to reproduce with the TigerVNC Viewer. The issue is triggered because the JPEG images generated on the server happen to be just the right size (or rather, the wrong size) for TigerVNC's custom libjpeg destination manager. Since the TigerVNC Viewer doesn't ever request JPEG quality 95 (it uses JPEG quality 92 instead, if the quality level is set to 8), the issue will be minimally much less frequent with that viewer, if it can be reproduced at all. However, the bug still exists in the TigerVNC Server, and I suspect that with sufficient digging, one could find image workloads that cause the issue with other JPEG quality levels. -- Because it's not readily reproducible with the TigerVNC Viewer, the TigerVNC developers don't seem to really care about it, and thus it doesn't seem to have been fixed. This is, BTW, one of the big reasons why I pulled out of that project. I don't understand why it's such a big deal for them to fix this in their server code, but it's far from the first time that I've butted heads with them over something that shouldn't have really been controversial. TigerVNC is a faster-moving project, to be sure, but this is what I mean when I say that there is an "irreconcilable clash of project management styles" between them and us (http://www.turbovnc.org/About/TigerVNC). I stand by my assessment that the TigerVNC developers need to work around this in their JPEG destination manager. I also strongly suspect that they won't. If there was a way for me to work around this in the TurboVNC Viewer, I would have done so long ago, but unfortunately the TigerVNC Server is sending us a corrupt JPEG, so there's not much we can do about it. You might try using JPEG image quality 92 instead of 95 to simulate the TigerVNC Viewer. That may at least make the bug less frequent. But I think switching to our server is the better solution. DRC On 3/15/16 9:02 AM, "Göbbert, Jens Henrik" wrote: > Hi, > > I am using TigerVNC server (tigervnc-server-1.3.1-3.el7.x86_64) > with VirtualGL (VirtualGL-2.4-4.el7.x86_64) > to run the visualization tool VisIt 2.10.0 (https://visit.llnl.gov) on > the server > (this software components are currently installed by the administrators). > > On my computer I use TurboVNC. > Often I get the following message from the TurboVNC viewer: > "Corrupt JPEG data: 908 extraneous bytes before marker 0xd9. Reconnect?" > The viewer disconnects and I cannot connect back, as the JPEG image is > still corrupt. > > We will switch to TurboVNC on server-side soon, so this error hopefully > disappears. > But for the record I send this mail. > > And last but not least: Thanks for the great TurboVNC! > > Best, > Jens Henrik > > P.S.: > This error has been reported by some other user here: > https://github.com/TigerVNC/tigervnc/issues/218 > and passed forward to > https://github.com/libjpeg-turbo/libjpeg-turbo/pull/27 > and passed back to TigerVNC. > > Everything started with this discussion: > https://sourceforge.net/p/turbovnc/mailman/turbovnc-users/thread/561C94FC.7060905%40users.sourceforge.net/#msg34535264 > > P.P.S: > The VNC connection info is: > Size 1912x1149 > Pixel format: depth 24 (32bpp) little-endian rgb888 > (server default depth 24 (32bpp) little-endian rgb888) > Requested encoding: Tight > Last used encoding: Tight > Protocol version: 3.8 > Security type: VncAuth [VncAuth] > JPEG decompression: Turbo > TurboVNC Helper: Loaded > > P.P.S.: > I can see corrupt icons in ParaView, too, but they do not stop TurboVNC > viewer to run. ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
