[TurboVNC-Users] corrupt JPEG data

[Göbbert, Jens Henrik]

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.



------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

[DRC]

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.

[Göbbert, Jens Henrik]

Hello DRC,

thanks for the detailed summary.

Grüße
Jens Henrik

________________________________________
From: DRC [***@users.sourceforge.net]
Sent: Tuesday, March 15, 2016 5:55 PM
To: turbovnc-***@lists.sourceforge.net
Subject: Re: [TurboVNC-Users] corrupt JPEG data

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
TurboVNC-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/turbovnc-users


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------