R and B colours are swapped with WebP encoding and non-opengl windows

[totaam]

Issue migrated from trac ticket # 650

component: encodings | priority: minor | resolution: fixed

2014-08-21 03:07:30: onlyjob created the issue

---

On 0.14.1 tray icons look funny (distorted colours) when "WebP" encoding is chosen.
I can see this only on tray icons and only with WebP encoding...
0.13.9 was OK.

[totaam]

2014-08-21 05:01:42: totaam changed owner from antoine to onlyjob

[totaam]

2014-08-21 05:01:42: totaam commented

---

That's odd, I can't reproduce (..), can you try with this very simple test application: [/browser/xpra/trunk/src/tests/xpra/test_apps/test_system_tray.py].

It works fine here and is definitely sent as webp:

$ xpra info | egrep "tray=|total_"
client.system_tray=True
window[1].total_frames[webp]=33
window[1].total_pixels[webp]=114816
window[1].tray=True

Please also post the output of ./xpra/codecs/loader.py

[totaam]

2014-08-21 06:26:32: onlyjob commented

---

xpra info (on server):

client.system_tray=True
window[1].tray=False
window[2].total_frames[rgb24]=23
window[2].total_frames[webp]=11
window[2].total_pixels[rgb24]=270372
window[2].total_pixels[webp]=5596648
window[2].tray=False
window[3].tray=False
window[5].total_frames[webp]=2
window[5].total_pixels[webp]=1152
window[5].tray=True
window[6].total_frames[webp]=2
window[6].total_pixels[webp]=1152
window[6].tray=True
window[7].total_frames[webp]=2
window[7].total_pixels[webp]=1152
window[7].tray=True
window[15].total_frames[webp]=2
window[15].total_pixels[webp]=1152
window[15].tray=True

loader.py (output for server and client is identical):

codecs and csc modules found:
* PIL                  : /usr/lib/python2.7/dist-packages/PIL/__init__.pyc
* enc_vpx              : /usr/lib/python2.7/dist-packages/xpra/codecs/vpx/encoder.so
* dec_vpx              : /usr/lib/python2.7/dist-packages/xpra/codecs/vpx/decoder.so
* enc_x264             : /usr/lib/python2.7/dist-packages/xpra/codecs/enc_x264/encoder.so
* enc_x265             : 
* nvenc                : 
* csc_swscale          : /usr/lib/python2.7/dist-packages/xpra/codecs/csc_swscale/colorspace_converter.so
* csc_cython           : /usr/lib/python2.7/dist-packages/xpra/codecs/csc_cython/colorspace_converter.so
* csc_opencl           : 
* dec_avcodec          : 
* dec_avcodec2         : /usr/lib/python2.7/dist-packages/xpra/codecs/dec_avcodec2/decoder.so
* enc_webp             : /usr/lib/python2.7/dist-packages/xpra/codecs/webp/encode.so
* dec_webp             : /usr/lib/python2.7/dist-packages/xpra/codecs/webp/decode.so

codecs versions:
* PIL                  : 2.5.1
* avcodec2             : 55.34.1
* cython               : 0.3.0.20.2
* dec_webp             : 0.4.0
* enc_webp             : 0.4.0
* swscale              : 2.1.2
* vpx                  : 1.3.0
* x264                 : 142

See attached image "tray-colors.png" with screenshot of "test_system_tray.py": icon on the left is the distorted one from Xpra session with WebP encoding; icon on the right is locally running app.

[totaam]

2014-08-21 06:26:54: onlyjob uploaded file tray-colors.png (3.4 KiB)

[totaam]

2014-08-21 06:58:39: totaam changed status from new to assigned

[totaam]

2014-08-21 06:58:39: totaam changed owner from onlyjob to totaam

[totaam]

2014-08-21 06:58:39: totaam commented

---

Hah, right, by distorted you don't mean that the picture's quality is degraded but that the colours are swapped, right? I didn't think of checking the colours!

I'll be able to test that better as soon as I figure out why the systray forwarding is misbehaving on Fedora 20... (I hope I don't have to deal with #405 just yet)

[totaam]

2014-08-21 09:06:41: totaam uploaded file color-test.png (14.9 KiB)

what the colour test should look like

[totaam]

2014-08-21 09:11:02: totaam commented

---

Another really useful test for colour mixups is this one [/browser/xpra/trunk/src/tests/xpra/test_apps/colors.py], it should look like this:
[[Image(color-test.png)]]
As you can see, it looks fine here with all colour encodings - does it on yours?
(and pressing a key can be used to start or pause a gradual change in colours useful for testing other things)

Another test which can be useful is this one: [/browser/xpra/trunk/src/tests/xpra/test_apps/transparent_colors.py] - especially considering that trays are transparent. It looks similar, except the window is part transparent and there is no animation

[totaam]

2014-08-21 12:28:56: onlyjob commented

---

Tried those test apps -- "transparent_colors.py" demonstrated a problem: swapped RED and BLUE (with WebP).
"colors.py" is OK as well as other encodings.

[totaam]

2014-08-21 15:08:37: totaam uploaded file Jessie-x86-transparent-colors.png (120.7 KiB)

transparent colours look fine on Debian Jessie

[totaam]

2014-08-21 15:09:19: totaam commented

---

Well, well.

First, I wasted a lot of time trying to figure out why my updated Jessie VM failed to connect.
It seems that something got updated very recently that completely broke the system tray support that we use (not that it ever worked properly under gnome3.. but now it deadlocks the whole application most of the time - sometimes it will work).
Wheezy I cannot test because it ships a version of libwebp which is just too old. Debian Sid worked fine every time - I tried 20 times to be sure (well gnome3 still hides the tray somewhere, but it doesn't just hang like Jessie) - I even did a full system update to see if the recent broken update also affected it, nope: still worked. I hope this gets fixed in Jessie sooner rather than later, it is pretty debilitating.
That's using a package OR installing from source. Both just hang at setting up the tray.

As you can see (after patching out the code that normally tries to setup the system tray):
[[Image(Jessie-x86-transparent-colors.png)]]

It worked fine for me (as usual..). I tried enabling opengl to see if it matters, but that crashes in virtualbox. Can you try disabling/enabling it? I guess you don't use gnome3 then? KDE IIRC?

[totaam]

2014-08-21 17:04:22: onlyjob commented

---

Of course I tried enabling/disabling OpenGL -- it makes no difference.
I'm on KDE but I doubt it could be significant.
The strange thing is that I'm still attached to the session where I reproduced the problem but transparent colors now OK (I run test again -- too bad I didn't take screenshot to prove that I'm not crazy) ;)
Tray icons show incorrect colours very reliably -- 100% (i.e. every time I choose WebP encoding)...

[totaam]

2014-08-21 17:16:30: onlyjob commented

---

I got it -- I was wrong regarding OpenGL -- it makes a difference.
Red and Blue are swapped in transparent_colors test only when OpenGL is disabled.
As soon as I tick OpenGL in Xpra menu colours are swapping back to normal.

[totaam]

2014-08-22 05:09:48: onlyjob commented

---

Looks like it is R-B colour swap issue not specific to tray...
I just reproduced on nouveau with "transparent_colors.py"...

[totaam]

2014-08-22 05:23:40: onlyjob commented

---

I built libwebp-0.3.0 from source; re-built Xpra and reproduced both issues -- this one (i.e. R-B colour swap) and vertical stripes in konsole #651.

[totaam]

2014-08-22 05:29:03: onlyjob commented

---

Same problems with libwebp-0.2.1 but konsole distortion pattern is slightly different: squares instead of stripes...

[totaam]

2014-08-22 05:47:55: totaam changed title from weird tray icons colours with WebP encoding to R and B colours are swapped with WebP encoding and non-opengl windows

[totaam]

2014-08-22 05:47:55: totaam commented

---

I've just seen it on Debian Sid, now I can reproduce the colour problem I should be able to fix it. The konsole one on the other hand (#651).. may be a different issue, maybe I need to also run the server on Debian for that one.

[totaam]

2014-08-22 07:01:32: totaam changed status from assigned to new

[totaam]

2014-08-22 07:01:32: totaam changed owner from totaam to onlyjob

[totaam]

2014-08-22 07:01:32: totaam commented

---

Bug was that we assumed that the client can upload pixels in BGRA format... which is the case for the opengl backing, but not for the plain gtk pixmap one used as fallback. Just like #651, I am amazed that no-one noticed this with opengl disabled.

Fixed in r7405, more improvements (not strictly necessary) in r7406.

Does that fix things? Will backport this fix and r7402 before releasing 0.14.2

[totaam]

2014-08-22 07:39:32: onlyjob commented

---

Replying to [comment:13 totaam]:

Fixed in r7405, more improvements (not strictly necessary) in r7406.

I tested both on 0.14.1 -- fixes work, problem solved. Thank you.

[totaam]

2014-08-22 07:52:38: totaam changed status from new to closed

[totaam]

2014-08-22 07:52:38: totaam changed resolution from ** to fixed

[totaam]

2014-08-22 07:52:38: totaam commented

---

Backport in 7407.

Thanks for testing!