Dithering artifacts with PNG 8 bit colour encoding

[allo-]

Describe the bug
When using PNG encoding, it seems like colors are dithered and I think in older versions they were just clamped to the nearest color in the palette. Even though it may look better for photos, dithered areas look like having artifacts when UI elements and other larger areas with a constant color are rendered and it would probably look better to map them to the nearest color, or provide an option to choose if colors should be dithered.

To Reproduce
Steps to reproduce the behavior:

1. Switch to PNG as video encoding
2. Open a window with some large single color area of a color that is not in the palette.

System Information (please complete the following information):

• Server OS: Debian stable
• Client OS: Debian stable
• Xpra Server Version: 6.0
• Xpra Client Version: 6.0

Additional Context
I wonder if the PNG palette is fixed or optimized for the current image. Many patches would probably not contain more than 256 colors if the palette would be adapted to the image contents.

[totaam]

When using PNG encoding, it seems like colors are dithered and I think in older versions they were just clamped to the nearest color in the palette

Please include a screenshot.

Switch to PNG as video encoding

PNG is not a video encoding.
Even when switching to png, the xpra server may still use other encodings as needed.
You can run the server with -d compress or the client with -d draw to see what is actually being used.
Or even use XPRA_PAINT_BOX=1 xpra attach to see it visually using colour-coding.

I wonder if the PNG palette is fixed or optimized for the current image.

png does not use a palette.
png/L and png/P do.

It must be something else, perhaps an issue with pre-multiplied alpha instead.

[allo-]

I meant "PNG 8 bit colour" and -d draw tells that PNG/P is indeed used.

It then looks like this:

[totaam]

OK, so not plain png then.
Don't use PNG 8 bit colour.
I very much doubt that it is any better than letting the xpra engine compress things.

[allo-]

I tried it because I was getting flickering with the automatic codec selection on a not so good internet connection. PNG 24-Bit is way too big and PNG/P used to be a good compromise for clean GUIs. I suspect it is just a switch in a library that was changed at some point and could either be exposed as a separate codec (PNG/P, PNG/P-dithering) or completely changed back.

[totaam]

I keep saying it again and again, documenting it, wikying it.
I even added a GUI in v6 to stop people messing with encodings: #4064 (comment)

[allo-]

I mostly have the requirement to display mostly static UIs with text and scroll them from time to time and am looking for how to achieve this with the best quality (no artifacts around text) using the given options. In the end, I would not care what makes it work, and setting PNG/P is just an option that has worked for me in the past, even though it may not have been intended to be used directly.

I wouldn't have configured anything if I didn't have flickering in the UI. Next time I can check which codec is causing the flickering. On the Debian testing system here the automatic codec suprisingly seems to select webp, but it also runs smoothly on this machine at the moment. I might open another issue for the flickering if I can reproduce it on the other machine and have debug output for the drawing.

I would appreciate any other suggestions for my use case that do not involve setting things you would prefer people not to mess with.

About the new UI: I don't see the new UI with Xpra 6.0 and 6.1 from your repositories. I still used the right click menu from the tray icon for setting the encoding and launched Xpra from the command line. If there are new warnings and new configuration UI, I have completely missed it so far.

[totaam]

If there are new warnings and new configuration UI, I have completely missed it so far.

Try xpra configure
fd3e265 also adds it to the GUI you get when running just xpra