On Fri Mar 27 23:01:19 2026 +0000, Jan Robert Gerigk wrote:
Windows does the same for the case I tested: converting 24bppBGR to Gray16 gives byte pairs like 04 04, 08 08, 0C 0C, which is the val\*257 pattern from an 8-bit intermediate step. Test output on Windows (24bppBGR -\> Gray16 first row): 00 00 04 04 08 08 0C 0C 10 10 14 14 18 18 1C 1C I only tested with 24bppBGR as source, so I should probably test a few more cases with higher bit depth sources. Unfortunately I just broke my Windows partition (0x69 boot error, no system image), so it will take a bit untill I can set this up again. The implementation reuses the existing copypixels_to_8bppGray as intermediate step, same as the other converters in the file do. Do you want me to add a dedicated higher precision intermediate path for Gray16 instead, or is matching the Windows behavior sufficient here? That's a little surprising.
My original plan was that the BGRA formats would be a sort of "hub", with 32bppBGRA being the main one (with individual faster paths added as needed), so more precise formats would go through e.g. 64bppBGRA or a float format, but when going from 32->64 we could go through 32bppBGRA first. But it seems like 64bppBGRA is the only higher precision format that has a fallback. Maybe native is doing something similar but skips the intermediate step for 8-bit formats. I don't think we have to match native exactly, but we don't have to be more precise than native either. I would just want to make sure that, if native is more precise for e.g. 64bppBGRA, we don't have that going through 8bppGray first. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10412#note_134386