@Sameer K Thanks for trying to reproduce the issue! With JPG files (and Camera Raw filter) I observe the desired behavior (effects settings do not reset). I've also tried to reproduce the issue on a different machine, but it behaved correctly with both raws and JPGs.   I did some digging and I think I've tracked down the root cause.   Before clicking the eye icon we need to create and set a Raw default profile.   Step 1 - Set texture, clarity and dehaze to distinct values (let's say 1, 2, 3) Step 2 - create a preset, name it "test_effects_reset", check only "Effects" (and possibly "Support Amount Slider", not tested with this unchecked) Step 3 - set this preset as camera raw default     Step 4: now set "texture, clarity and dehaze" to some random values. Press & hold & release the eye icon. The sliders are reset to the value from the "Raw Default" preset, not to the previously set value.   Step 5: set the "Raw Default" to "Adobe Default". The problem is gone - the sliders are reset back to the previous value after releasing the mouse button.   Could you please try to reproduce this issue with "Raw Defaults" set? ... View more

@CJButler thanks! I would be grateful if you would consider, as a last resort, changing to the non-Async version guarded by a flag in PSUserConfig.txt (let's say: `UseNonAsyncKBModifiers 1`) . That way only the bravest of the users would be exposed to potentially breaking change. I'm keeping my fingers crossed for the review! ... View more

@CJButler Thanks! I'm very grateful for you quick and honest responses. I'm curious, if this issue happens also on non-Windows platforms. I'm not even trying to imagine the complexity and layers that grew over the years. I'm myself very, very, surprised that ditching the Async version solved the problem on my end. I will use the patched version for a while and report any issues. But I use a very specific subset of functionalities (no artboards, no stroke smoothing, etc.) and this change might have impact that is hard to predict, even with access to the source code.   > how this negatively impacts your day-to-day workflow, It's manageable. But the original issue (with moved layer) happens ~2x day. I have to redo some work ~x1 month, as I usually notice the layer shift, and have enough history to undo, but it's irritating.   > and whether your workarounds are tolerable or not I'm OK with running the patched file, but every new release (especially beta releases that happen very often), would require me to create a new patch. Time consuming, but better than having layers randomly moved.   Adding to my previous post, I did a little more digging. Fortunately `GetKeyState` is present in the imports table. I was able to find a single call in Photoshop binary that has to be patched. It's a very small stub, called from >50 other places, but at least I don't have to patch a system-level dll.   If you are interested in trying my workaround, here is the patch (you can use https://hexed.it/) for Photoshop.exe: For "Adobe Photoshop Version 25.11.0 20240716.r.706 b326a7d x64", file offset 0x00A303C6, change 96 to D6 For "BETA Adobe Photoshop Version 25.12.0 20240722.m.2708 7e0e5ce x64", file offset 0x27927D6, change 3EB0 to CEAF (all it does is changing a call to GetAsyncKeyState into a call to GetKeyState)   ... View more

Well... it was that simple 🙂 At least it seems to solve both problems I've described and is not breaking anything obvious.   I've hot-patched GetAsyncKeyState (in user32.dll) to jmp directly to GetKeyState. This is quite heavy-handed, but it's a good place to start. There are many justified uses of the Async versions for sure, and patching them all willy-nilly will break something else. But if you can pinpoint the call used in the drawing/scheduling code path, that might be it 🙂 ... View more

@CJButler thanks for logging the bug!   The lag of a big brush is to be expected and I have no issue with that.   > One thing that might be done is to somehow reject KB modifiers while a brush stroke is still painting. Yes, that might solve this particular issue, but would not address the root cause.   I've tried sampling a color (by Alt+clicking, releasing Alt immediately) while the stroke was being painted. That revealed another strange behavior. A single dot is being painted in the place where I sampled a color from, as if I just clicked there, without holding the Alt key. On the other hand, when I paint a "slow" stroke, then click without holding Alt, and press & hold Alt after clicking, a color is sampled instead of painting a dot in the place I clicked.   I can only speculate how the code works, but it seems like the KB modifiers are read using GetAsyncKeyState (which ignores the message queue) to decide what tool operation should be scheduled (brush, move, sample color), whereas mouse/pen events are processed from the event queue. If the modifiers keys were also read from the event queue (using GetKeyState, without Async), then the state of modifier keys should be updated appropriately for the tool choice. It should solve those odd behaviors, but I guess it is not that simple... ... View more

@Nicole26080976f51u  > will eliminate the alert for 25.11 If you experience this issue in 25.11 please share a sample file. For me, it works as expected in 25.11 (no "update" alert displayed) ... View more

@Nicole26080976f51u Have you tried the latest beta (Adobe Photoshop Version: 25.12.0 20240722.m.2708 7e0e5ce x64)? I can no longer experience this issue after update. The newest non-beta Photoshop (July 2024 release (version 25.11)) also doesn't want to update any text layers. ... View more

I've got rid of that "save the new target colors as default" dialog myself. If someone is interested how to do it, please DM me. ... View more

I still stick to Bridge 2022, new versions are unusable for me.   Bridge 2022 is almost perfect - snappy (current version: laggy), previews load instantly (current version: I see low-res preview for about 1s after selecting a photo), filtering works fast (current version: feels slower and laggier), star rating and filenames do not take too much space (current version: they take too much space), dark theme is good (current version: dark theme is unusable). ... View more

Only a workaround. See one of my previous posts. From what I understand Adobe consider it as WAI. ... View more

Thanks Cory! I switch between Beta and non-Beta versions, and don't want to modify/update the text layers back and forth. If there is no way to disable this new text engine features in Beta, I will simply stop using Beta and wait for the non-Beta text engine to catch up. ... View more

Hi @CShubert! Yes, that was originally a part of "fake colors" layer buried deep inside many groups. I've included only the problematic layer, to give you a minimal example. There were also other text layers using the same font, but only this one caused the message to pop up.   I've created another test file ("test2-clean.psd"), starting from an empty doc and dragging the text layer over. Same issue. (I wasn't able to attach it to the response, had to edit the original post. The original attachment disappeared...)   >  Do you see the same issue with other files as well, or just this file? Only this file. Although I don't normally use text layers at all, and I have no other files with text layers created from scratch.   > What do you think is unique to this file vs others... No idea, sorry 😞   I've opened the "test2-clean.psd" file in PS Beta, clicked "update", and saved as "test2-clean-after-updating.psd". I've then parsed both PSD files to look for differences. I've found a change in "cinf" layer tag ("COMPOSITOR_INFO") of the text layer:       before updating: minorlong\u0\u0\u0\t \u0\u0\u0\u3fixlong\u0\u0\u0\u1\u0\u0\u0\u0 after updating: minorlong\u0\u0\u0\u0b\u0\u0\u0\u3fixlong\u0\u0\u0\u0\u0\u0\u0\u0 ^^^^ ^^^       I haven't parsed the compositor info itself and I have no idea what's the meaning of those fields.   I observed this unexpected behavior for the first time, let's say, 1..2 months ago. Older Beta versions did not show this message. It should be possible to run a binary search (like git bisect) to find a commit that introduced this bug. ... View more

@Sameer K FYI: the bug is still present in ACR 16.4.0.1906 ... View more

@Sameer K Thanks!   There was also a similar bug regarding the preview not updating while moving the Amount slider by mouse pretty fast, maybe it's connected: https://community.adobe.com/t5/camera-raw-discussions/amount-slider-in-masking-breaks-when-moving-too-fast/m-p/14602156#M25006   ... View more

I have created this thread as a "bug" and provided all required info. It was changed to "discussion". It is NOT a discussion. Why someone changed that category? Please change it back to "bug", so that we can track progress. Thanks! ... View more

@CShubert could you please take a look? ... View more

Thanks! @Rikk Flohr: Photography please let me know if you need more info to be able to reproduce this issue. ... View more

Severity: > How is this impacting your workflow? Medium impact, but very distracting.    > What workarounds have you come up with? No workarounds found.   > Is this blocking you from getting your work done? It impacts the time needed to set up masks. When I create masks with very subtle effect I want to be able to quickly disable and re-enable the mask with custom amount. I can use the eye icon to toggle visibility, but I want to have control over the amount too. ... View more

More context, based on a message from @CJButler (thanks!):   > From what I can tell, the problem is not a lost event, but one of the slider > value being out of sync with what is currently being displayed. Correct.   > One thing that might be helpful to offer the ACR team is whether > the min/max value is actually applied to the data. ; i.e. is the slider > number wrong on the control display, or is the preview wrong and > the underlying data actuallyhas had the indicated setting applied correctly.    The slider value is being displayed correctly, but it is not applied to the data, i.e. the preview shows the effect applied as if the slider was in the middle possiotion.   You can see that in my screen recording - when I move mouse to the left (fast! way over the left edge of the slider), the slider value reads 0 (correct), "Light" panel is disabled (correct), but the preview still shows (incorrect) dark circle, as if the Amount slider was reading ~170 (the value just before draggigng it to the left). The preview gets updated to the correct state after releasing left mouse button.   If you move the slider slowly to the left, both the slider value and the effect visible stay in sync, both in the middle and at the "0" possition. ... View more

I was able to reproduce this issue on another two Windows 10 PC with latest updates.   Any luck on reproduing this issue on Adobe side? Do you need more info? ... View more

Workaround, using AHK (Windows): #IfWinActive, Camera Raw ^1::Send e^1^1 ^2::Send e^2^2 ^3::Send e^3^3 ^4::Send e^4^4 ^5::Send e^5^5   ... View more

@Erik Bloodaxe Thanks! does that imply that the first of the three numbers cannot exceed 99 since it appears to be allocated just two characters? No, just drop the space after the comma Like this:     "spectrum-global-color-blue-400": "rgb(29, 128, 245)" - original "spectrum-global-color-blue-400": "rgb(255,128, 245)" - modified     I've also hacked my way around the bright app and menu bar on Windows ( https://community.adobe.com/t5/bridge-discussions/white-menu-and-application-bar-even-in-the-dark-and-darkest-theme/m-p/14481282#M49050 ), if you are interested.   ---   ... View more