DirectX 11 Win7 versus Win8 difference in brightness/shader ambient lighting - wpf

Question

The problem shows on all Win8 systems, all brands, all types of desktop, laptop, all-in-one, and tablets (tested on nearly every system at BestBuy which there's a ton of them so I can't be the first person to see this.)
What is happening is shown in below image (note captions below each surface), where the rendering on Win8 is brighter than Win7 for native code and WinForm which is based off a windowed ID3D11Device/Context; and to make things worse; the rendering is darker via WPF and WPFs shared surface/texture features though using similar device/context. The actual rendering loop and shaders are identical. Win7/Vista render the same/ideal brightness via native type render target or WPF shared surface.
The DirectX 11 code was developed on Win7. It's very basic DX stuff and the shader is as simple a shader as possible; very similar to the most basic DirectX SDK examples.
Why is DX11 Win8 brightness not consistent with Win7? Gradients seem different too.
Why would Win8 WPF shared surface/texture create even more difference?
What is the best strategy to solve such rendering brightness differences?
I did end up answering, but welcome improvements or expand with related answers to brightness/lighting problems between win7 and win8 as searching the net for such topic shows little results.

Answer 1

After much work between me and MS, (MS wanted a repro without using DXUT even though I told them PNTriangles11 caused the issue and it was a wild goose chase.) I found it was related to EnumOutputs failing on Win8 (MS still to provide an official reason, I will update) and DXUT portions that call EnumOutputs fail resulting in the problematic section of code DXUTApplyDefaultDeviceSettings(DXUTDeviceSettings *modifySettings)
where...
modifySettings->d3d11.sd.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM_SRGB;
should be changed to...
modifySettings->d3d11.sd.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
which resolves the issue and color is consistent between Win7 and Win8. MS pointed this out. Though I'd like to know why EnumOutputs is failing on Win8 and MS is likely the only one possible to answer this. EnumOutputs failed on every Win8 system at BestBuy, all types of systems.
As for another DXUT modification needed for Win8 compatibility, within DXUTChangeDevice, adding a test for nonzero hAdapterMonitor is likely wanted...
bool bNeedToResize = false;
if(hAdapterMonitor && DXUTGetIsWindowedFromDS( pNewDeviceSettings ) && !bKeepCurrentWindowSize )
{
UINT nClientWidth;
UINT nClientHeight;
if( ::IsIconic( DXUTGetHWNDDeviceWindowed() ) )
For completeness as relates to topic title, gamma correction information can be found at directx gamma correction and new windows 8 brightness control features for integrated displays win8 brightness control

Answer 2

I'm currently testing my C++,DX10 program (based on DXUT June 2010) on Windows 8,
And I'm having the same problems.
Here are additional changes/advice that I advice to do on DXUT:
1) do NOT use the arguments /width, /height, /windowed, /fullscreen in the strExtraCommandLineParams of DXUTInit
2) in DXUTGetMonitorInfo, s_pFnGetMonitorInfo( hMonitor, lpMonitorInfo ); returns FAIL on my system.
So I have replaced this line by something like:
BOOL success = s_pFnGetMonitorInfo( hMonitor, lpMonitorInfo );
//try to return the less wrong result
if ( !success )
{
RECT rcWork;
if ( lpMonitorInfo &&
( lpMonitorInfo->cbSize >= sizeof( MONITORINFO ) ) &&
SystemParametersInfoA( SPI_GETWORKAREA, 0, &rcWork, 0 )
)
{
lpMonitorInfo->rcMonitor.left = 0;
lpMonitorInfo->rcMonitor.top = 0;
lpMonitorInfo->rcMonitor.right = GetSystemMetrics( SM_CXSCREEN );
lpMonitorInfo->rcMonitor.bottom = GetSystemMetrics( SM_CYSCREEN );
lpMonitorInfo->rcWork = rcWork;
lpMonitorInfo->dwFlags = MONITORINFOF_PRIMARY;
return TRUE;
}
return FALSE;
}
else
{
return TRUE;
}
3) Concerning the brightness (gamma correction),
if have added:
if ( BackBufferFormat == DXGI_FORMAT_R8G8B8A8_UNORM_SRGB )
{
return false;
}
in my callback IsD3D10DeviceAcceptable, so I ban every gamma correction device.
And now everything seems to work
(BTW, I'm not sure to understand your "hAdapterMonitor &&" modification, because it doesn't use directly this pointer, but maybe we don't have the same DXUT version )