https://bugs.freedesktop.org/show_bug.cgi?id=46631
--- Comment #8 from Neil Roberts <[email protected]> 2012-02-26 13:41:46 UTC --- Ok, I think I understand this a bit better now. I think the problem is that Mesa is doing the wrong thing when converting from the framebuffer format to the temporary floating point RGBA representation. According to the GL 3.0 spec in the section on reading pixels, it says “Internal components are converted to an RGBA color by taking each R, G, B, and A component present according to the base internal format of the buffer (as shown in table 3.15). If G, B, or A values are not present in the internal format, they are taken to be zero, zero, and one respectively”. Table 3.15 shows that the L component of an internal luminance format maps to only the R component. Mesa is currently mapping the luminance value to all three components. You can see that on the proprietary Nvidia driver it only maps to the R component because if you set the R scale to 0.0 when reading the pixels you get 0.0 back for the luminance. So I guess we could make a patch that changes the luminance functions in format_unpack.c to only copy to the R component. However I'm not sure if this will break other things because those functions are also used in a lot of other places. It is clearly a separate bug though so for now I'll just make the luminance patch obsolete and we can file another bug sometime. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
