Re: [Tigervnc-users] tigervnc 1.0.1 colors wrong when viewing on ppc mac
I've tested libjpeg-turbo by building it as a PPC binary on my Mac, and
it appears to work as expected, and all of its unit tests pass. The
convention for both libjpeg-turbo and the TurboJPEG wrapper is that
ABCD means that A is at a lower memory address than D, and this
convention is consistently used throughout the project. The other
TurboJPEG incarnations, such as the mediaLib version and IPP versions,
use the same convention.
And, in fact, upon closer examination, this is the convention that
TigerVNC is attempting to use as well (in tightDecode.h.) My assertion
in the previous message was incorrect. The pseudo code for TigerVNC is
as follows:
if(X server is big endian) {
if(red shift==16 green shift==8 blue shift==0) use XRGB;
if(red shift==0 green shift==8 blue shift==16) use XBGR;
} else {
if(red shift==16 green shift==8 blue shift==0) use BGRX
if(red shift==0 green shift==8 blue shift==16) use RGBX;
}
The X server takes the convention that RGBX (red/green/blue
shift=0/8/16) means that red is the LSB of the word, which is why we
have to do the pixel flipping ourselves to accommodate that, since the
codec uses a different convention. However, now that I re-examine the
code, I don't see any problems with it.
In short, I have no idea why the pixels aren't being displayed properly
in TigerVNC. All I can figure is that they are being reversed in some
other part of the code. If I break down TurboVNC into the same
pseudo-code, it is doing exactly the same thing, and TurboVNC is known
to work on big endian platforms.
DRC
On 2/2/11 4:50 PM, DRC wrote:
Yeah, those values should be causing cinfo.out_color_space to be set to
JCS_EXT_XRGB, which is what we intended. However, I think I now
understand why there is a mismatch (bear with the long-winded
explanation, as I am doing this partly so I can get it straight in my
own head):
When you decompress a JPEG image in libjpeg-turbo, you can specify how
the red, green, and blue pixels are ordered in the destination RGB
image, as well as the size of each RGB pixel. This is accomplished by
setting the output color space to RGB, BGR, RGBX, BGRX, XRGB, or XBGR.
This controls where the red, green, and blue components end up after the
YUV-to-RGB conversion. Let's take two neighboring RGB pixels {R0, G0,
B0} and {R1, G1, B1}. The various libjpeg-turbo colorspace options
would store the bytes as follows (in order of increasing memory addresses):
JCS_EXT_RGB: R0, G0, B0, R1, G1, B1
JCS_EXT_BGR: B0, G0, R0, B1, G1, R1
JCS_EXT_RGBX: R0, G0, B0, XX, R1, G1, B1, XX
JCS_EXT_BGRX: B0, G0, R0, XX, B1, G1, R1, XX
JCS_EXT_XRGB: XX, R0, G0, B0, XX, R1, G1, B1
JCS_EXT_XBGR: XX, B0, G0, R0, XX, B1, G1, R1
The opinion on whether or not this is correct for a big endian machine
seems to vary. One convention takes RGBX to mean: R is at a lower
address than G, which is at a lower address than B, which is at a lower
address than X. That is the convention that libjpeg-turbo follows, and
there are other APIs that follow the same convention. Others say that
RGBX means: R is the least significant byte, and X is the most
significant. Given the latter convention, a 32-bit RGBX pixel {R0, G0,
B0} should be written (in order of increasing memory location) as R0,
G0, B0, XX on little endian machines and XX, B0, G0, R0 on big endian
machines. The latter convention seems to be what I was trying to follow
in tightDecode.h, so that's why there is a mismatch. TurboVNC seems to
also use the latter convention, so it would likely fail in the same way
when built against libjpeg-turbo on a big endian system.
At this point, I've managed to confuse myself as to what the right
approach is here. I think it's probably to modify libjpeg-turbo so that
its convention is for A to be the LSB and D to be the MSB in an
ABCD pixel, but I really need to log some time on a big endian machine
(any volunteers?) and play with it to convince myself of that.
If anyone else has any sage advice as to what the right convention is,
please post. I can't seem to find any official word about this on the web.
DRC
On 2/2/11 6:21 AM, cwjor...@cox.net wrote:
DRC,
Thanks for your quick reply. The Solaris machine is Intel.
As you suggested I edited common/rfb/tightDecode.h to add the following at
line 274:
printf (Debug: redShift = %d\n, redShift);
printf (Debug: greenShift = %d\n, greenShift);
printf (Debug: blueShift = %d\n, blueShift);
printf (Debug: pf.bigEndian = %d\n, pf.bigEndian);
compiled it and ran that version of vncviewer.
On the PPC mac I get the following output:
Debug: redShift = 8
Debug: greenShift = 16
Debug: blueShift = 24
Debug: pf.bigEndian = 1
and the colors on the display are wrong.
On the Intel mac I get:
Debug: redShift = 16
Debug: greenShift = 8
Debug: blueShift = 0
Debug: pf.bigEndian = 0
and the colors on the display are right.
Chris Jordan
DRC
Re: [Tigervnc-users] tigervnc 1.0.1 colors wrong when viewing on ppc mac
Yeah, those values should be causing cinfo.out_color_space to be set to
JCS_EXT_XRGB, which is what we intended. However, I think I now
understand why there is a mismatch (bear with the long-winded
explanation, as I am doing this partly so I can get it straight in my
own head):
When you decompress a JPEG image in libjpeg-turbo, you can specify how
the red, green, and blue pixels are ordered in the destination RGB
image, as well as the size of each RGB pixel. This is accomplished by
setting the output color space to RGB, BGR, RGBX, BGRX, XRGB, or XBGR.
This controls where the red, green, and blue components end up after the
YUV-to-RGB conversion. Let's take two neighboring RGB pixels {R0, G0,
B0} and {R1, G1, B1}. The various libjpeg-turbo colorspace options
would store the bytes as follows (in order of increasing memory addresses):
JCS_EXT_RGB: R0, G0, B0, R1, G1, B1
JCS_EXT_BGR: B0, G0, R0, B1, G1, R1
JCS_EXT_RGBX: R0, G0, B0, XX, R1, G1, B1, XX
JCS_EXT_BGRX: B0, G0, R0, XX, B1, G1, R1, XX
JCS_EXT_XRGB: XX, R0, G0, B0, XX, R1, G1, B1
JCS_EXT_XBGR: XX, B0, G0, R0, XX, B1, G1, R1
The opinion on whether or not this is correct for a big endian machine
seems to vary. One convention takes RGBX to mean: R is at a lower
address than G, which is at a lower address than B, which is at a lower
address than X. That is the convention that libjpeg-turbo follows, and
there are other APIs that follow the same convention. Others say that
RGBX means: R is the least significant byte, and X is the most
significant. Given the latter convention, a 32-bit RGBX pixel {R0, G0,
B0} should be written (in order of increasing memory location) as R0,
G0, B0, XX on little endian machines and XX, B0, G0, R0 on big endian
machines. The latter convention seems to be what I was trying to follow
in tightDecode.h, so that's why there is a mismatch. TurboVNC seems to
also use the latter convention, so it would likely fail in the same way
when built against libjpeg-turbo on a big endian system.
At this point, I've managed to confuse myself as to what the right
approach is here. I think it's probably to modify libjpeg-turbo so that
its convention is for A to be the LSB and D to be the MSB in an
ABCD pixel, but I really need to log some time on a big endian machine
(any volunteers?) and play with it to convince myself of that.
If anyone else has any sage advice as to what the right convention is,
please post. I can't seem to find any official word about this on the web.
DRC
On 2/2/11 6:21 AM, cwjor...@cox.net wrote:
DRC,
Thanks for your quick reply. The Solaris machine is Intel.
As you suggested I edited common/rfb/tightDecode.h to add the following at
line 274:
printf (Debug: redShift = %d\n, redShift);
printf (Debug: greenShift = %d\n, greenShift);
printf (Debug: blueShift = %d\n, blueShift);
printf (Debug: pf.bigEndian = %d\n, pf.bigEndian);
compiled it and ran that version of vncviewer.
On the PPC mac I get the following output:
Debug: redShift = 8
Debug: greenShift = 16
Debug: blueShift = 24
Debug: pf.bigEndian = 1
and the colors on the display are wrong.
On the Intel mac I get:
Debug: redShift = 16
Debug: greenShift = 8
Debug: blueShift = 0
Debug: pf.bigEndian = 0
and the colors on the display are right.
Chris Jordan
DRC dcomman...@users.sourceforge.net wrote:
More than likely so. The color shifting would be consistent with trying
to draw an RGBX bitmap when the system expects XRGB, and I used to see
the same problems on Sparc TurboVNC clients whenever the pixel format
wasn't converted properly. The code that handles that in TigerVNC
(common/rfb/tightDecode.h) looks correct to me, but I don't know if
anyone has actually tested it on a big endian X server.
Do you have any way to insert a print statement at line 273 in that file
(or run it in gdb) and determine what redShift, greenShift, blueShift,
and pf.bigEndian are being set to on your client machine? That will
tell me whether or not our guess as to what cinfo.out_color_space should
be set to on big endian machines is correct.
Also, I am assuming this works correctly when you connect using a little
endian client? You didn't specify whether or not the Solaris machine
was Sparc or not, but I'm assuming not.
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Tigervnc-users mailing list
Tigervnc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-users
--
Special Offer--
Re: [Tigervnc-users] tigervnc 1.0.1 colors wrong when viewing on ppc mac
More than likely so. The color shifting would be consistent with trying to draw an RGBX bitmap when the system expects XRGB, and I used to see the same problems on Sparc TurboVNC clients whenever the pixel format wasn't converted properly. The code that handles that in TigerVNC (common/rfb/tightDecode.h) looks correct to me, but I don't know if anyone has actually tested it on a big endian X server. Do you have any way to insert a print statement at line 273 in that file (or run it in gdb) and determine what redShift, greenShift, blueShift, and pf.bigEndian are being set to on your client machine? That will tell me whether or not our guess as to what cinfo.out_color_space should be set to on big endian machines is correct. Also, I am assuming this works correctly when you connect using a little endian client? You didn't specify whether or not the Solaris machine was Sparc or not, but I'm assuming not. On 2/1/11 6:39 PM, cwjor...@cox.net wrote: If I ssh from my old PPC mac into my opensolaris server (running openindiana build 148 or opensolaris build 134) and start running tigervnc 1.0.1 to connect to the local host by running vncviewer 0, the session, as viewed on my mac, has the colors all shifted - white becomes yellowish, blue becomes green, etc. I thought perhaps there is a problem with how tiger vnc is handling the PPC mac being a big-endian machine? Connection Info shows: Desktop name: x11 Host: 0 port: 5900 Size: 1024 x 768 Pixel format: depth 24 (32bpp) big-endian rgb888 (server default depth 24 (32bpp) little-endian rgb 888) Requested encoding: Tight Last used connection: Tight Line speed estimate: 20015 kbit/s Protocol version: 3.8 Security method: None Changing the color depth doesn't make a difference. This worked fine when I used to use tightvnc, and works fine from an Intel mac. Anyone have any thoughts? Chris Jordan -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Tigervnc-users mailing list Tigervnc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-users -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Tigervnc-users mailing list Tigervnc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-users
