error windows 2h22

[ledoge]

error windows 2h22

[ectv96]

is there any clue if this issue is being fixed or not?

[lauralex]

I will release a modified version of the program, ported to C++ and with the updated offsets etc.

[markanini]

Same issue after upgrading to 22H2, definitly Microsoft updated DWM. Hopefully this will be fixed in the end, just be patient.

Microsoft is finally getting around to a color managed desktop.

https://devblogs.microsoft.com/directx/auto-color-management/

https://github.com/dantmnf/MHC2 It's holding me over while dwm_lut is being updated for 22H2.

[el-ef]

Will there be an update any time soon? :)

[EmotiveColor]

Seconded - is there any progress? I just updated to W11 yesterday, and was devastated to discover that DwmLutGUI has been broken

[ledoge]

Hi, sorry for the radio silence on my part, with recent work stuff and some PC issues I just haven't had any motivation to work on/think about this stuff. Glad to see that @lauralex is working on it now though :)

I checked my notes and IDA database, and I believe this is how I obtained the remaining offsets:

• IOverlaySwapChain_IDXGISwapChain_offset should just be the difference between the second arguments of COverlayContext::Present and CD3DDevice::Present when you set breakpoints in both (and ideally only have one monitor active, so you know they'll correspond to the same one)
• COverlayContext_DeviceClipBox_offset_w11 should be the difference between the first argument of COverlayContext::Present and the address of the first float value accessed in CLegacyRenderTarget::IsPrimaryMonitor

[ledoge]

Yeah, I didn't even try to reverse the actual C++ stuff going on, I just used dynamic analysis and breakpoints to figure out all the offsets.

[StomaNL]

Same issue after upgrading to 22H2, definitly Microsoft updated DWM. Hopefully this will be fixed in the end, just be patient.

[lauralex]

I'm trying to reverse the updated dwmcore dll and find some way to fix the dwm_lut program

[lauralex]

Anyway, use the following AoB pattern search algorithm, it's more robust:

bool aob_match_inverse(const void* buf1, const void* mask, const int buf_len)
{
	for (int i = 0; i < buf_len; ++i)
	{
		if (((unsigned char*)buf1)[i] != ((unsigned char*)mask)[i] && ((unsigned char*)mask)[i] != '?')
		{
			return true;
		}
	}
	return false;
}

[lauralex]

I'm trying to reverse the updated dwmcore dll and find some way to fix the dwm_lut program

Sounds promising! Where can we follow the progress?

Right now I'm comparing Windows 10 offsets with Windows 11 ones. I have one laptop with Windows 10 and a PC with Windows 11. I'm doing remote debugging of the DWM.EXE process from the Windows 11 machine to the Windows 10 laptop and I managed to verify the offset for the hardware protection flag, which is -0xBC for the W10 OS.

[lauralex]

I managed to find the new IOverlaySwapChain_HardwareProtected_offset_w11, which should be -0x12C, but I'm still working at finding the rest, i.e., I_OverlaySwapChain_IDXGISwapChain_offset_w11 and COverlayContext_DeviceClipBox_offset_w11

[lauralex]

The new pattern for COverlayContext_Present for Windows 11 is: {
0x40, 0x53, 0x55, 0x56, 0x57, 0x41, 0x56, 0x41, 0x57, 0x48, 0x81, 0xEC, '?', '?', '?', '?', 0x48, 0x8B, 0x05, '?',
'?', '?', '?', 0x48, 0x33, 0xC4
}

The new pattern for COverlayContext_IsCandidateDirectFlipCompatbile for Windows 11 is: {
0x40, 0x55, 0x53, 0x56, 0x57, 0x41, 0x54, 0x41, 0x55, 0x41, 0x56, 0x41, 0x57, 0x48, 0x8B, 0xEC, 0x48, 0x83, 0xEC,
0x68, 0x48, 0x8B, 0x05, '?', '?', '?', '?', 0x48, 0x33, 0xC4, 0x48, 0x89, 0x45, 0xF0
}

The new pattern for COverlayContext_OverlaysEnabled for Windows 11 is: {
0x83, 0x3D, '?', '?', '?', '?', '?', 0x75, 0x04, 0x32, 0xC0, 0xC3, 0xCC, 0x83, 0x79, 0x2C, 0x01, 0x0F, 0x97, 0xC0,
0xC3
}

[lauralex]

@lauralex Can someone help you somehow here with this? I mean, maybe there is a task, that requires a lot of not very complicated actions to be done, so someone without highest coding skills could make this part? I apologize if I'm saying something completely irrelevant, I'm not a coder at all, so I don't understand, what is DXGISwapChain and all that stuff unfortunately.

If the dwmcore dll didn't change much, all that needs to be done is to find the correct offsets for the IOverlaySwapChain_HardwareProtected_offset_w11, COverlayContext_DeviceClipBox_offset_w11 and IOverlaySwapChain_IDXGISwapChain_offset_w11. Unfortunately, to do this, some Reverse Engineering skills are required, the tools I'm using right now are IDA and some plugins like Sig Maker and HexRaysCodeXplorer

[lauralex]

The final offset for the first float number of the device clipbox should be +0x466C with respect to the address pointed by the COverlayContext

[lauralex]

dll injection works fine, I have to fix the offset relative to the IDXGISwapChain which is a little bit wrong, because when the hooked COverlayContext::Present method is executed, something bad happens. It's almost finished.
Anyway, this is my forked repo (WIP) with the DLL solution ported to C++ and with added debug messages just to check if everything works fine: https://github.com/lauralex/dwm_lut.

Remember to create a directory named DWMLOG in your filesystem root or edit the LOG_FILE_PATH macro. It is used to log some events during the dll execution which help me understand why something goes bad.
Or you can disable the debug mode setting the DEBUG_MODE macro to false

[lauralex]

Guys, I got it working, finally!

[EmotiveColor]

Just want to note, I tried compiling it and found the last two compile instructions should be (forward slash):
./bootstrap-vcpkg.bat
./vcpkg integrate install

And I want to note that both the lutdwm.sln and DwmLutGUI.sln projects need to be compiled, and the contents of their respective x64/Release & bin/x64/Release folders copied into one folder to run the gui .exe.

To disable the debug hook messages for the compiled dll, set #define DEBUG_MODE to false in lutdwm.sln

The compiled .exe won't cause the Windows Defender flag to be activated. Perhaps this false flag can be reported to Microsoft to get the program .exe whitelisted.

[adbowers]

Same issue after upgrading to 22H2, definitly Microsoft updated DWM. Hopefully this will be fixed in the end, just be patient.

Microsoft is finally getting around to a color managed desktop.

https://devblogs.microsoft.com/directx/auto-color-management/

[el-ef]

My wallet w'd be ready. 😅

@ledoge

[antonmeleshkevich]

@lauralex Can someone help you somehow here with this? I mean, maybe there is a task, that requires a lot of not very complicated actions to be done, so someone without highest coding skills could make this part?
I apologize if I'm saying something completely irrelevant, I'm not a coder at all, so I don't understand, what is DXGISwapChain and all that stuff unfortunately.

[lauralex]

Ahahahah, I spent like three days filling my IDA database with types, virtual tables, etc.

[lauralex]

It's insane

[lauralex]

In summary, the new found offsets are:

• -0x12C (for the Hardware Protection flag)
• +0xE0 (for the IDXGISwapChain instance)

I just have to get the offset for the DeviceClipBox
UPDATE:

• -0X144 (For the hardware protection flag)

[antonmeleshkevich]

I will release a modified version of the program, ported to C++ and with the updated offsets etc.

You're going to make a christmas miracle for so many people! Thanks!

[lauralex]

You have to compile the source code

Yea, that's what I gathered from the date stamps. Gutthikas probably downloaded the exe to get that error.

Yeah, still, I have to fix something, because I discovered that the shader is not compiled correctly for some reason, in fact, I get an error during the execution of the D3DCompile function. Anyway, I'm gonna update my repo with an improved code

[lauralex]

Oh fuck, you cannot see the difference, because the screenshot doesn't get the actual LUT lol

[lauralex]

Code updated, go check the repo

[EmotiveColor]

Bravo! You did that in record time, on New Year's Eve no less.

[Buliwyf-Stonehand]

Just wanted to note for those reading, I'm trying to compile the .sln project file with Visual Studio, and found that there is a dependency on MinHook.h.

Is there a way to update the description section on the fork? Currently, the compiling instruction applies to the original dwm_lut.c file compile process, and the 'Download Latest Release' goes to the old .exe.

You could use vcpkg to handle dependencies.

[EmotiveColor]

If it is a small file, you can upload here

Ok, here it is. It no longer has false color in the grayscale, and the saturation model is naturalized. That means that start bar problem will be fixed. Also, the color is 'clean' - there will be no artifacts/banding in gradients. More saturation probably aids in color separation, and I tried to preserve higher saturation for the purpose of the Ishihara test. So there will be less saturation for that purpose, but the benefit is that the color model is now a lot more natural for things like skintone.

deuteranomaly_emotive_hybrid.zip

[EmotiveColor]

This one is better, thanks

Sure, glad I could be of assistance. Feel free to include it in DaltoLAB if you wish.

[EmotiveColor]

Okay.

"Once more, with feeling." Just one more, I promise. These are 0.0-0.5 & 0.0-0.4, which may be a good compromise for you. More saturation on the Ishihara, while retaining naturally saturated skintone:
deuteranomaly_emotive_to_.zip

[ectv96]

same here too

[definfo]

#20

[antonmeleshkevich]

I rolled back to windows 10 in a moment I realized this awesome app doesn't support win11 22h2 yet (got the same error). Can't imagine my PC not having dwm lut ♥️

[antonmeleshkevich]

Hope it will still be possible to use DWM LUT with this new 22h2 color management. It's always been everything wrong with ICC implementations for calibration and profiling displays. I'm talking about sRGB vs Gamma 2.2 display assumed EOTF holy wars.

[markanini]

I'm talking about sRGB vs Gamma 2.2 display assumed EOTF holy wars.

It's not that contentious. Calibration tools use a pure 2.2 gamma with sRGB/Rec.709 primaries as the default target. Tagged content displays correctly on color managed apps, which take account for TRC differences. Untagged content displays ok with the assumed sRGB/2.2 target because it's an average of uncalibrated displays native output.

[antonmeleshkevich]

Despite I "watch all activity" of this repo and get everything from here to my email, I'm still checking any news here almost everyday :)
Really the only thing that holds me from switching to Windows 11.

[antonmeleshkevich]

@ledoge if the update takes too much time to starting working on it, maybe it would be better to make the app paid?

[antonmeleshkevich]

I'm trying to reverse the updated dwmcore dll and find some way to fix the dwm_lut program

Sounds promising! Where can we follow the progress?

[gutthikas]

Will there be an update any time soon?

[lauralex]

Will there be an update any time soon?

Hi, I'm trying to find out the offset for the IDXGISwapChain in W11. I'm still new to Windows Reverse Engineering and this stuff, so I might take some time. Do you know how you got the offset in the first place?
I verified that the old offset for W10: -0x118 is correct, but I don't know why the DXGISwapChain object is placed at that location (with respect to the OverlaySwapChain object)

[lauralex]

Hi, sorry for the radio silence on my part, with recent work stuff and some PC issues I just haven't had any motivation to work on/think about this stuff. Glad to see that @lauralex is working on it now though :)

I checked my notes and IDA database, and I believe this is how I obtained the remaining offsets:

• IOverlaySwapChain_IDXGISwapChain_offset should just be the difference between the second arguments of COverlayContext::Present and CD3DDevice::Present when you set breakpoints in both (and ideally only have one monitor active, so you know they'll correspond to the same one)
• COverlayContext_DeviceClipBox_offset_w11 should be the difference between the first argument of COverlayContext::Present and the address of the first float value accessed in CLegacyRenderTarget::IsPrimaryMonitor

Oh, so you suggest doing remote debugging and checking the differences between these addresses

[lauralex]

Ok I found out the offset for the new IDXGISwapChain**, which should be +0x0E0

[lauralex]

Hi, sorry for the radio silence on my part, with recent work stuff and some PC issues I just haven't had any motivation to work on/think about this stuff. Glad to see that @lauralex is working on it now though :)

I checked my notes and IDA database, and I believe this is how I obtained the remaining offsets:

• IOverlaySwapChain_IDXGISwapChain_offset should just be the difference between the second arguments of COverlayContext::Present and CD3DDevice::Present when you set breakpoints in both (and ideally only have one monitor active, so you know they'll correspond to the same one)
• COverlayContext_DeviceClipBox_offset_w11 should be the difference between the first argument of COverlayContext::Present and the address of the first float value accessed in CLegacyRenderTarget::IsPrimaryMonitor

Actually you cannot just get the difference by setting a breakpoint, because only the double pointer to the IDXGISwapChain is static, so I just reversed the logic of the the CD3DDevice::Present method callers (CLegacySwapChain::Present -- COverlayContext::Present)

[EmotiveColor]

I don't know anything about reversing, only C++. What does one do with offsets, once figured out?

[EmotiveColor]

I will release a modified version of the program, ported to C++ and with the updated offsets etc.

Ah very cool. It will be great to have it in C++!

[gutthikas]

[EmotiveColor]

dll injection works fine, I have to fix the offset relative to the IDXGISwapChain which is a little bit wrong, because when the hooked COverlayContext::Present method is executed, something bad happens. It's almost finished. Anyway, this is my forked repo (WIP) with the DLL solution ported to C++ and with added debug messages just to check if everything works fine: https://github.com/lauralex/dwm_lut.

Remember to create a directory named DWMLOG in your filesystem root or edit the LOG_FILE_PATH macro. It is used to log some events during the dll execution which help me understand why something goes bad. Or you can disable the debug mode setting the DEBUG_MODE macro to false

Do you need to compile the fork code rather than download the exe directly? I clicked 'Download the Latest Release' on the fork page, and received the above error message. My latest Windows 11 update is "2022-12 Cumulative Update for Windows 11 Version 22H2 for x64-based Systems (KB5021255)"

[lauralex]

dll injection works fine, I have to fix the offset relative to the IDXGISwapChain which is a little bit wrong, because when the hooked COverlayContext::Present method is executed, something bad happens. It's almost finished. Anyway, this is my forked repo (WIP) with the DLL solution ported to C++ and with added debug messages just to check if everything works fine: https://github.com/lauralex/dwm_lut.
Remember to create a directory named DWMLOG in your filesystem root or edit the LOG_FILE_PATH macro. It is used to log some events during the dll execution which help me understand why something goes bad. Or you can disable the debug mode setting the DEBUG_MODE macro to false

Do you need to compile the fork code rather than download the exe directly? I clicked 'Download the Latest Release' on the fork page, and received the above error message. My latest Windows 11 update is "2022-12 Cumulative Update for Windows 11 Version 22H2 for x64-based Systems (KB5021255)"

You have to compile the source code

[EmotiveColor]

You have to compile the source code

Yea, that's what I gathered from the date stamps. Gutthikas probably downloaded the exe to get that error.

[lauralex]

In the meantime, this is the error I got:

Trying to compile vshader with this code:
 struct VS_INPUT { float2 pos : POSITION; float2 tex : TEXCOORD; }; struct VS_OUTPUT { float4 pos : SV_POSITION; float2 tex : TEXCOORD; }; Texture2D backBufferTex : register(t0); Texture3D lutTex : register(t1); SamplerState smp : register(s0); Texture2D noiseTex : register(t2); SamplerState noiseSmp : register(s1); int lutSize : register(b0); bool hdr : register(b0); static float3x3 scrgb_to_bt2100 = { 2939026994.L / 585553224375.L, 9255011753.L / 3513319346250.L, 173911579.L / 501902763750.L, 76515593.L / 138420033750.L, 6109575001.L / 830520202500.L, 75493061.L / 830520202500.L, 12225392.L / 93230009375.L, 1772384008.L / 2517210253125.L, 18035212433.L / 2517210253125.L, }; static float3x3 bt2100_to_scrgb = { 348196442125.L / 1677558947.L, -123225331250.L / 1677558947.L, -15276242500.L / 1677558947.L, -579752563250.L / 37238079773.L, 5273377093000.L / 37238079773.L, -38864558125.L / 37238079773.L, -12183628000.L / 5369968309.L, -472592308000.L / 37589778163.L, 5256599974375.L / 37589778163.L, }; static float m1 = 1305 / 8192.; static float m2 = 2523 / 32.; static float c1 = 107 / 128.; static float c2 = 2413 / 128.; static float c3 = 2392 / 128.; float3 SampleLut(float3 index) { float3 tex = (index + 0.5) / lutSize; return lutTex.Sample(smp, tex).rgb; } void barycentricWeight(float3 r, out float4 bary, out int3 vert2, out int3 vert3) { vert2 = int3(0, 0, 0); vert3 = int3(1, 1, 1); int3 c = r.xyz >= r.yzx; bool c_xy = c.x; bool c_yz = c.y; bool c_zx = c.z; bool c_yx = !c.x; bool c_zy = !c.y; bool c_xz = !c.z; bool cond; float3 s = float3(0, 0, 0); #define ORDER(X, Y, Z) cond = c_ ## X ## Y && c_ ## Y ## Z; s = cond ? r.X ## Y ## Z : s; vert2.X = cond ? 1 : vert2.X; vert3.Z = cond ? 0 : vert3.Z; ORDER(x, y, z) ORDER(x, z, y) ORDER(z, x, y) ORDER(z, y, x) ORDER(y, z, x) ORDER(y, x, z) bary = float4(1 - s.x, s.z, s.x - s.y, s.y - s.z); } float3 LutTransformTetrahedral(float3 rgb) { float3 lutIndex = rgb * (lutSize - 1); float4 bary; int3 vert2; int3 vert3; barycentricWeight(frac(lutIndex), bary, vert2, vert3); float3 base = floor(lutIndex); return bary.x * SampleLut(base) + bary.y * SampleLut(base + 1) + bary.z * SampleLut(base + vert2) + bary.w * SampleLut(base + vert3); } float3 pq_eotf(float3 e) { return pow(((((pow(e, 1 / m2) - c1)) > (0)) ? ((pow(e, 1 / m2) - c1)) : (0)) / (c2 - c3 * pow(e, 1 / m2)), 1 / m1); } float3 pq_inv_eotf(float3 y) { return pow((c1 + c2 * pow(y, m1)) / (1 + c3 * pow(y, m1)), m2); } float3 OrderedDither(float3 rgb, float2 pos) { float3 low = floor(rgb * 255) / 255; float3 high = low + 1.0 / 255; float3 rgb_linear = pow(rgb, 2.2); float3 low_linear = pow(low, 2.2); float3 high_linear = pow(high, 2.2); float noise = noiseTex.Sample(noiseSmp, pos / 64).x; float3 threshold = lerp(low_linear, high_linear, noise); return lerp(low, high, rgb_linear > threshold); } VS_OUTPUT VS(VS_INPUT input) { VS_OUTPUT output; output.pos = float4(input.pos, 0, 1); output.tex = input.tex; return output; } float4 PS(VS_OUTPUT input) : SV_TARGET{ float3 sample = backBufferTex.Sample(smp, input.tex).rgb; if (hdr) { float3 hdr10_sample = pq_inv_eotf(saturate(mul(scrgb_to_bt2100, sample))); float3 hdr10_res = LutTransformTetrahedral(hdr10_sample); float3 scrgb_res = mul(bt2100_to_scrgb, pq_eotf(hdr10_res)); return float4(scrgb_res, 1); } else { float3 res = LutTransformTetrahedral(sample); res = OrderedDither(res, input.pos.xy); return float4(res, 1); } } 
ERROR AT LINE: 585 HR: -2147467259 - DETAILS: Unspecified error
 - DX COMPILE ERROR: C:\WINDOWS\system32\Shader@0x00007FFEE1F82011(1,1576): error X3000: syntax error: unexpected token '#'
C:\WINDOWS\system32\Shader@0x00007FFEE1F82011(1,1647-1649): error X3018: invalid subscript 'X'

Exception caught at line 713: ERROR AT LINE: 585 HR: -2147467259 - DETAILS: Unspecified error
 - DX COMPILE ERROR: C:\WINDOWS\system32\Shader@0x00007FFEE1F82011(1,1576): error X3000: syntax error: unexpected token '#'
C:\WINDOWS\system32\Shader@0x00007FFEE1F82011(1,1647-1649): error X3018: invalid subscript 'X'


Exception caught at line 870: ERROR AT LINE: 585 HR: -2147467259 - DETAILS: Unspecified error
 - DX COMPILE ERROR: C:\WINDOWS\system32\Shader@0x00007FFEE1F82011(1,1576): error X3000: syntax error: unexpected token '#'
C:\WINDOWS\system32\Shader@0x00007FFEE1F82011(1,1647-1649): error X3018: invalid subscript 'X'

It can be something about the MSVC Preprocessor

[lauralex]

The problem is that the MSVC preprocessor puts everything in one line, so the macros inside the shader are not property written.
One simple solution is to let the MSVC preprocessor fuck itself, and just use a simple raw string literal in C++

[lauralex]

I will push all the updates, I'm very happy

[lauralex]

This is my color corrected screen for deuteranomaly:

This is the original, without the LUT:

[lauralex]

Original:

With LUT applied:

[lauralex]

Okay, these are taken from my phone:

Corrected:

Original:

[lauralex]

BTW, this is my deuteranomaly project: https://github.com/lauralex/daltoLAB

[EmotiveColor]

Just wanted to note for those reading, I'm trying to compile the .sln project file with Visual Studio, and found that there is a dependency on MinHook.h.

Is there a way to update the description section on the fork? Currently, the compiling instruction applies to the original dwm_lut.c file compile process, and the 'Download Latest Release' goes to the old .exe.

[lauralex]

Just wanted to note for those reading, I'm trying to compile the .sln project file with Visual Studio, and found that there is a dependency on MinHook.h.

Is there a way to update the description section on the fork? Currently, the compiling instruction applies to the original dwm_lut.c file compile process, and the 'Download Latest Release' goes to the old .exe.

Yeah, you are right, I forgot to update the page description, instructions, etc.. I'm gonna update it soon

[lauralex]

You have already done it, you can make a PR if you want

[EmotiveColor]

Apologies if my questions are foolish, I am a complete newb to Git (pretty unconventional coder)

[EmotiveColor]

Btw, with the deuteranomaly project, it's cool, but I was wondering if you meant for the blackish start bar to go red (non-colorblind person here)?

[lauralex]

Btw, with the deuteranomaly project, it's cool, but I was wondering if you meant for the blackish start bar to go red (non-colorblind person here)?

No, if look at the Isihara tables between the corrected image and the original image, you can see the difference in colors. I am a deuteranomaly color blind person, so I can clearly see the difference

[lauralex]

Oh sorry I didn't understand the question, no actually I have to fix the LUT a little bit, I wouldn't want the task bar to go red, so I have to improve the LUT by enhancing the LAB parameters somehow

[EmotiveColor]

Oh sorry I didn't understand the question, no actually I have to fix the LUT a little bit, I wouldn't want the task bar to go red, so I have to improve the LUT by enhancing the LAB parameters somehow

I've written some powerful color tools that may be of use somehow (with tweaking). Is your lut the .3dl in your linked project?

[lauralex]

Oh sorry I didn't understand the question, no actually I have to fix the LUT a little bit, I wouldn't want the task bar to go red, so I have to improve the LUT by enhancing the LAB parameters somehow

I've written some powerful color tools that may be of use somehow (with tweaking). Is your lut the .3dl in your linked project?

No I use the .cube format. It's not in the repository. I have some functions in the lut.util.py file that convert a .3dl lut into a .cube lut, but I didn't test them extensively

[lauralex]

Oh sorry I didn't understand the question, no actually I have to fix the LUT a little bit, I wouldn't want the task bar to go red, so I have to improve the LUT by enhancing the LAB parameters somehow

I've written some powerful color tools that may be of use somehow (with tweaking). Is your lut the .3dl in your linked project?

I have also updated the daltoLAB repo with the .cube file I'm using

[EmotiveColor]

I have also updated the daltoLAB repo with the .cube file I'm using

Nice, I was trying to tweak my poor .3dl code that wasn't handling it correctly. The proper lut is now 'lutCreatorJs.cube'?

[lauralex]

or .3dl code that wasn't handling it correctly. The proper lut is now 'lutCreatorJs.

Yeah, lutCreatorJs.cube, which I created using the lutCreator website, very useful

[EmotiveColor]

Yeah, lutCreatorJs.cube, which I created using the lutCreator website, very useful

I've started messing around. Stay tuned, you may be in for a treat.

[EmotiveColor]

Yeah, lutCreatorJs.cube, which I created using the lutCreator website, very useful

It's already massively improved with clean gradients. But to get the holy grail of a perfectly neutral gamma in both linearity and color, I'm going to need to code a custom function just for this task. A question - is your LAB solution intended to preserve ideal translations of color *brightness (not just hue rotations)?

You could use vcpkg to handle dependencies.

Right on ;)

[EmotiveColor]

Yeah, lutCreatorJs.cube, which I created using the lutCreator website, very useful

Alright, it's coded and working well. Now, I have some questions. The original lut hyper-saturates color - do you want to preserve natural saturation and luma going out along each hue? Skintone looks a lot more natural to my eye this way, while completely preserving the deuteranomaly hue angles (for color separation purposes). It can also be weighted towards the original saturation and luma values of the lut, while being completely neutral in the gamma. Let me know.

[antonmeleshkevich]

Guys, I got it working, finally!

Thanks a million, @lauralex !!!
Looks like I can finally update to Windows 11!

Is there any difference in performance compared to @ledoge version? I mean since you have rewritten everything in C++, does it mean it became slower of faster? Or it has no effect on performance? Or the resulting app is the same and changing the language affects the coding itself only, not the result? I apologize again for my dumb questions:)

Do we have to compile it by ourselves or you've updated the compiled version as well?

And regarding screenshots - I found it very useful, that it's not applied to screenshots. One example is screen sharing. I can stream my screen without the LUT applied for the capture, but still see the image calibrated using LUT.

[lauralex]

Guys, I got it working, finally!

Thanks a million, @lauralex !!! Looks like I can finally update to Windows 11!

Is there any difference in performance compared to @ledoge version? I mean since you have rewritten everything in C++, does it mean it became slower of faster? Or it has no effect on performance? Or the resulting app is the same and changing the language affects the coding itself only, not the result? I apologize again for my dumb questions:)

Do we have to compile it by ourselves or you've updated the compiled version as well?

And regarding screenshots - I found it very useful, that it's not applied to screenshots. One example is screen sharing. I can stream my screen without the LUT applied for the capture, but still see the image calibrated using LUT.

I didn't encounter any performance drawbacks

[lauralex]

Do we have to compile it by ourselves or you've updated the compiled version as well?

I can release the artifact as a zip

[EmotiveColor]

I can release the artifact as a zip

Ok well, just trying to pay it forward here (Luts/color are kinda my wheelhouse, unlike github..). Anyway, here is a comparison of the original deuteranomaly lut, and a new hybrid of the two fore-mentioned approaches to saturation/luma. The gamma is now perfectly neutral, and gradients are smooth:

Original Lut:

New Hybrid:

Original Lut:

New Hybrid:

Original Lut:

New Hybrid:

[lauralex]

I can release the artifact as a zip

Ok well, just trying to pay it forward here (Luts/color are kinda my wheelhouse, unlike github..). Anyway, here is a comparison of the original deuteranomaly lut, and a new hybrid of the two fore-mentioned approaches to saturation/luma. The gamma is now perfectly neutral, and gradients are smooth:

Original Lut:

New Hybrid:

Original Lut:

New Hybrid:

Original Lut:

New Hybrid:

Okay, I just released the artifact. Go check the repo

[EmotiveColor]

Okay, I just released the artifact. Go check the repo

Ok, let me know if you want me to upload the hybrid deuteranomaly lut (or modify it in some way)

[lauralex]

Okay, I just released the artifact. Go check the repo

Ok, let me know if you want me to upload the hybrid deuteranomaly lut (or modify it in some way)

Okay, where is this hybrid LUT?

[EmotiveColor]

I just made it today. Would you like me to upload it/send it to you, and where to?

[lauralex]

If it is a small file, you can upload here

[lauralex]

Did you try my release with W10? Because a friend of mine has W10 and the DLL injection doesn't work. It's strange, because the offsets should be correct

[lauralex]

If it is a small file, you can upload here

Ok, here it is. It no longer has false color in the grayscale, and the saturation model is naturalized. That means that start bar problem will be fixed. Also, the color is 'clean' - there will be no artifacts/banding in gradients. More saturation probably aids in color separation, and I tried to preserve higher saturation for the purpose of the Ishihara test. So there will be less saturation for that purpose, but the benefit is that the color model is now a lot more natural for things like skintone.

deuteranomaly_emotive_hybrid.zip

Ok thanks, I'll try it

[lauralex]

If it is a small file, you can upload here

Ok, here it is. It no longer has false color in the grayscale, and the saturation model is naturalized. That means that start bar problem will be fixed. Also, the color is 'clean' - there will be no artifacts/banding in gradients. More saturation probably aids in color separation, and I tried to preserve higher saturation for the purpose of the Ishihara test. So there will be less saturation for that purpose, but the benefit is that the color model is now a lot more natural for things like skintone.

deuteranomaly_emotive_hybrid.zip

Nice, I tried it. It successfully corrects the colors without changing them too much

[markanini]

I've only tested in W11 21H2 so far, and it give me an error :) I expect it to work when I test in 21H2 shortly. I will report back.

[lauralex]

I've only tested in W11 21H2 so far, and it give me an error :) I expect it to work when I test in 21H2 shortly. I will report back.

Maybe you meant 22H2

[markanini]

I've only tested in W11 21H2 so far, and it give me an error :) I expect it to work when I test in 21H2 shortly. I will report back.

Maybe you meant 22H2

You read my mind. I'm back on 22H2 now and your exe is working perfectly! I did have to temporarily disable windows defender and make an exception. Well done, I think this will make many users happy.

[EmotiveColor]

You read my mind. I'm back on 22H2 now and your exe is working perfectly! I did have to temporarily disable windows defender and make an exception. Well done, I think this will make many users happy.

Just want to note that I received the flag as well. Defender identifies it as a 'Severe' threat, thinking it is 'Trojan:Win32/Wacatac.H!ml'. Defender actually deleted the exe. I wonder what aspect of it that changed causes this flagging? Could it be the circumvention of the shader macro issue?

[EmotiveColor]

Nice, I tried it. It successfully corrects the colors without changing them too much

Indeed, the hue angles are locked to that of the original lut (most important part for translating for deuteranomaly). The saturation (and luma) had to naturally taper down to the grayscale to resolve the false color issue and artifacted gray values, so it was just a matter of finding an ideal balance for that taper. I made a more naturalized version, with a bit less saturation on the Ishihara:
deuteranomaly_emotive_natural.zip

Here is a comparison of the waveform of the original compared to this natural version (using more unforgiving Trilinear interpolation - the gamma should be a flat white line from the lower left corner to the upper right corner):

Original:

Naturalized:

[lauralex]

Nice, I tried it. It successfully corrects the colors without changing them too much

Indeed, the hue angles are locked to that of the original lut (most important part for translating for deuteranomaly). The saturation (and luma) had to naturally taper down to the grayscale to resolve the false color issue and artifacted gray values, so it was just a matter of finding an ideal balance for that taper. I made a more naturalized version, with a bit less saturation on the Ishihara: deuteranomaly_emotive_natural.zip

Here is a comparison of the waveform of the original compared to this natural version (using more unforgiving Trilinear interpolation - the gamma should be a flat white line from the lower left corner to the upper right corner):

Original:

Naturalized:

Okay, I'm trying it now

[lauralex]

This one is better, thanks

[EmotiveColor]

This one is better, thanks

One more for you, this time with the saturation/luma transition occurring over the entirety of the saturation run, from 0.0 to 1.0. This will be the most natural (i.e. approximate to true normal saturation), albeit with less artificial saturation boost for an easy Ishihara test. Furthermore, there is a bit of hue smoothing to resolve some of the messy clashes between magenta/green that I was seeing on the Gradient Chart:
deuteranomaly_emotive_full_natural.zip

Original Full Color Image:

[lauralex]

Okay. Anyway, there may be some performance drawbacks when the LUT filter is applied. Maybe, the shader code can be optimized, I don't know, but I estimate around 5% performance loss when the LUT program is enabled.
I tested it on Call of Duty Warzone 2 (DMZ), which is not a very optimized game xD

[EmotiveColor]

Okay. Anyway, there may be some performance drawbacks when the LUT filter is applied. Maybe, the shader code can be optimized, I don't know, but I estimate around 5% performance loss when the LUT program is enabled. I tested it on Call of Duty Warzone 2 (DMZ), which is not a very optimized game xD

Is that different than how dwm_lut performed before?

[EmotiveColor]

Okay.

Btw, the previous two deuteranomaly luts can be simply averaged (with different strengths allotted to each in the mix) to find an exact middleground that you might prefer.

[lauralex]

Okay.

"Once more, with feeling." Just one more, I promise. These are 0.0-0.5 & 0.0-0.4, which may be a good compromise for you. More saturation on the Ishihara, while retaining naturally saturated skintone: deuteranomaly_emotive_to_.zip

Should I add all of them to my daltoLAB repo? Or just the last one?

[EmotiveColor]

Whichever you think best. I'm flying blind here (pun intended), as I can't perceive the way you do. To my eye (and granted we all see the same source light at least), I think the more natural saturation is preferable for viewing a wider array of content than just trying to make the Ishihara test as clear as possible. Because I don't fully understand the LAB constraints you need to meet, the .4 or .5 compromises may be optimal for retaining the original luma/sat balance of the LAB transform past .4/.5 (with heightened saturation for the Ishihara goal).

[CrHasher]

I don't even have 22h2 version of Windows 11 and dwmlut only works until I go full-screen, as soon as I go full-screen dwm crashes and as a result dmlut gets diactivated or also crashes:

dwm crash:

Faulting application name: dwm.exe, version: 10.0.22000.1, time stamp: 0x7cbe2305
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00007ff80000004f
Faulting process id: 0x2d9c
Faulting application start time: 0x01d92375e46e02b1
Faulting application path: C:\Windows\system32\dwm.exe
Faulting module path: unknown
Report Id: e1408bb6-1304-41a9-9f14-07fa16900263
Faulting package full name: 
Faulting package-relative application ID: 

dwmlut crash (.NET Runtime):

Application: DwmLutGUI.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ComponentModel.Win32Exception
   at System.Diagnostics.NtProcessManager.GetModuleInfos(Int32, Boolean)
   at System.Diagnostics.ProcessManager.GetModuleInfos(Int32)
   at System.Diagnostics.Process.get_Modules()
   at DwmLutGUI.Injector.GetStatus()
   at DwmLutGUI.MainViewModel.UpdateActiveStatus()
   at System.Windows.Threading.DispatcherTimer.FireTick(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
   at System.Windows.Application.RunDispatcher(System.Object)
   at System.Windows.Application.RunInternal(System.Windows.Window)
   at DwmLutGUI.App.Main()

dwmlut crash (App):

Faulting application name: DwmLutGUI.exe, version: 1.0.0.0, time stamp: 0x62af39ec
Faulting module name: KERNELBASE.dll, version: 10.0.22000.1335, time stamp: 0x003161e5
Exception code: 0xe0434352
Fault offset: 0x000000000004441c
Faulting process id: 0x238c
Faulting application start time: 0x01d923764622c8b2
Faulting application path: D:\OneDrive\Documents\Data\Config\_DRIVERS & SETTINGS\_GENERAL\Monitor (Asus PG279Q)\DwmLut\DwmLutGUI.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 96f95798-84de-4629-af3f-23e7d6ce055f
Faulting package full name: 
Faulting package-relative application ID: