The current YUV to RGB conversion provides values in studio-range [16-235], but full-range is required [0-255]. As a result, we currently write the value of 16 to represent black, and so we get gray instead.
This MR changes the coefficients used in the conversion so that the resultant output is in full-range. It actually uses two sets of coefficients as these differ between SD and HD.
Also included is a number of Direct Draw 7 tests.
The coefficients used are documented here:
https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-…
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7324
On Thu Feb 13 12:40:06 2025 +0000, Brian Wright wrote:
> I've updated the [bug
> report](https://bugs.winehq.org/show_bug.cgi?id=57603) with some debug
> logs from 10.1 including `+x11drv,+event,+cursor,+win,+hid` if this helps.
@rbernon On the client side, if you wanted to know why the log produces the values it has or had advice on code changes, the relevant file seems to be [yabridge/src/wine-host/editor.cpp](https://github.com/robbert-vdh/yabridge/… and a few routines responsible for coords and mouse handling that might be indirectly showing up in the bug report log include **is_cursor_in_wine_window** (line 1442), **get_current_pointer_position** (line 953), **fix_local_coordinates** (line 785), and `case XCB_CONFIGURE_NOTIFY` (line 552)
I can attach to Wine and/or yabridge in a debugger, but I wouldn't have advice on what to change since I don't know how the handle relationships should look in order to find out which routine is producing incorrect coordinate offsets. If you want me to try anyway, I can put it in the queue of all the other stuff I forget to do once the workday is over.
Thanks to you and @robbert-vdh for maintaining two phenomenal tools.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_94461