Screenshots and other feedback

[raycornea]

Hello, here are the results after testing a bit the latest v1.11.1

• Screenshots : they include the popup Save As (to the folder/location) window, which is undesired for a screenshot
• Screenshots : i would suggest the option of having a persistent custom directory set in directory and a toggle/boolean always save screenshots to this location, if On will save to that location, if off will ask the user to save at certain location. It is somewhat uncomfortable to choose a save loaction while gaming
• (not sure if this is intended) Windows screenshots (Win + PrtScr) doesn't capture the NR effect, tested with SDR/HDR and OBS fix on/off

Other feedback notes:

• App window cannot be dragged from assigned Monitor to another
• Tested on second HDR TV : with 'HDR' setting on it works perfectly, with 'HDR' off the screen keeps flickering randomly.
• FPS : i am still not sure why i see such big spikes in fps, maybe it's just reading incorrectly since in one of the builds i saw a note about not calculating on static frames or something similar.

Log attached

NeuralScreen.log

[perseval-BLR]

Thanks for the detailed feedback. v1.12.0 is now available: https://github.com/perseval-BLR/NeuralScreen/releases/tag/v1.12.0

Fixed in this release:

• The processed frame is now frozen before the screenshot Save As dialog opens, so the dialog should no longer appear in the saved image.
• The HDR-off TV flicker in your log was the same DXGI format 10 (FP16) / 87 (BGRA8) capture loop reported in screen flickering v1.11.0 #86. SDR capture now requests a stable BGRA8 format through DuplicateOutput1.

Clarification: fullscreen NeuralScreen intentionally uses WDA_EXCLUDEFROMCAPTURE to prevent recursive self-capture. Therefore Windows screenshots and ordinary OBS display capture do not include the NR layer. Use NeuralScreen's built-in screenshot, Spout2, or capture the one-window mode instead.

Still open / not implemented in v1.12:

• a persistent “always save screenshots” toggle and custom screenshot directory (the current folder only seeds the Save As dialog);
• dragging the fullscreen output between monitors — monitor selection remains explicit;
• clearer separation of processing FPS, display FPS, and skipped static frames.

Please retest the screenshot-dialog and HDR-off flicker fixes. I am keeping this issue open for the remaining UX items.

[raycornea]

Thank you for the quick fix and the clarification

• Fixed : Screenshot has the correct frozen frame
• Not Fixed : HDR-off TV flicker. From my testing, it seems that the flicker is not based of NR being on, but the app itself. I turned NR off and the flicker persisted until i close the app. The flicker appears upon switching the display (monitor) in settings to the HDR display (monitor), and disappears if HDR option is turned on or if the program is closed, i tested with other options (Boost and 4.5 FG without any effect).

Here is the log, in case it is of any help

NeuralScreen.log

[perseval-BLR]

The new log confirms the same v1.12 behavior: 1,991 FP16/BGRA8 switches. v1.13 applies the stronger SDR DuplicateOutput/BGRA8 path; local real-GPU DDA smoke had no format rebuild. The screenshot fix is already confirmed, and v1.13 also adds persistent output folders and separate processing/output/skipped-frame metrics. Keeping this open for an HDR-off TV retest.

[perseval-BLR]

v1.13.0 is out: NeuralScreen v1.13.0.

Two things from your report are fixed there:

• Save As in the screenshot: the processed frame is frozen before the dialog opens, so the dialog cannot appear in the saved image.
• SDR flicker on the HDR TV: SDR capture now goes through the original DuplicateOutput converted to a stable BGRA8 (your log showed 1,991 FP16/BGRA8 switches); DuplicateOutput1 is reserved for HDR. Local smoke on the SDR path: 12 frames, no format-bridge rebuilds.

Please retest on v1.13.0 and send a fresh log if the flicker or the brightness anomaly remains - HDR brightness across GPUs is the part that is still yours to confirm, not something I can reproduce locally.

[raycornea]

tested on v1.13.1

[Completed]

• 'Save as' and auto save work nicely

[Bugs]

• Switching from HDR display to SDR resulted in endless load screen (HDR option was still on).
• The App popup/menu (in settings) is flickering (whole window, normal - full black window) after pressing Select screenshot folder, and moving the cursor while the choose folder dialog is on. Happened on SDR display with hdr off option, no such bug on HDR display with hdr option on.
• Flickering persists, i have attached a video aswell
• Auto menu off on 'NR On' is nice but if possible to have this as an option (sometimes you want to customize the effect). Also, on the TV (with settings hdr on), after NR On > popup dissapeared > Menu toggle (num2) moved cursor to a position at center up on screen (no menu) > toggled several times with the same bug. The menu appeared as it should once i turned off the NR (num1).
• Some screenshots resulted in black screen with just the app menu in view (attached bellow), tested with jpg format only.
• App window appears in every screenshot altough it is invisible on screen (menu was toggled off beforehand via NR On num1).

Thank you for your hard work on constantly improving this app

Log:
NeuralScreen.log

Flickering video:
https://github.com/user-attachments/assets/331ce121-67c3-4f0d-bbe1-cec7ced33f14

Black screenshots:

[perseval-BLR]

Thanks for testing v1.13.1 and for attaching the log, the video and the screenshots. The log answers the flicker question with a number.

The flicker: 1,955 bridge rebuilds in 2.5 minutes

21:03:29 .. 21:05:42
  [cap] capture format 10 -> 87 - rebuilding the bridge    1,501 times
  [cap] capture format 87 -> 10 - rebuilding the bridge      454 times

Format 10 is FP16, 87 is BGRA8 - and that rebuild is what you see as flicker.

The cause is in what we ask the driver for. With HDR compatibility on, the capture requests DuplicateOutput1 with a list of two formats:

const DXGI_FORMAT hdr_formats[] = { DXGI_FORMAT_R16G16B16A16_FLOAT,
                                    DXGI_FORMAT_B8G8R8A8_UNORM };

The driver may hand back either one, and on your driver/TV pair it alternates between them every frame. v1.13 fixed exactly this class for the SDR path - it now uses the original DuplicateOutput, which DXGI converts to one stable BGRA8 ([dda] SDR capture fixed to BGRA8 through legacy duplication). The HDR path kept the two-format list, and that is where this comes from.

It also matches your own observation: no flicker on the HDR display with HDR on, because there the driver stays on FP16. Your TV is SDR ([dda] output colour space 12, 8 bits per colour) while HDR compatibility is on, so the duplication runs in the high-colour mode with an unstable format. I am looking at requesting a single format instead of a list. I am not going to promise a date for it.

Black screenshots: confirmed

I looked at the JPEGs you attached: the background is black (mean brightness 4 of 255), the panel is drawn on the right, and the status reads "not processing".

Your log shows the sequence - screenshot requested - capturing before Save As -> frame pipeline resumed -> the file is written. With NR off the pipeline is suspended, so a screenshot has to bring it back for one frame, and that frame is taken before a picture has returned from the worker. Saving that is wrong: a screenshot should either wait for a real processed frame or refuse with a message.

HDR -> SDR: 18.6 seconds, not endless

21:13:18.476  [video] DDA1 OK (0x0)
[main] monitor change: 1 -> 0
21:13:37.057  [host] adapter 0: NVIDIA GeForce RTX 5080 ...

That is the gap between your monitor switch and the new worker coming up. Long enough to look stuck, but not a hang. What was on screen during it - the blurred veil, or plain black? And did it recover on its own, or did you have to restart the program?

The menu after NR on, and the cursor moving

In the log the menu opens and closes several times in a row with no other event between them, and the cursor is moved to the menu title after a screenshot. What the log cannot tell me is what you actually pressed. If it reproduces: was the menu open when you hit Num1, and did it disappear by itself - or did you press Num2 and it did not come back?

The panel appearing in a screenshot

The menu is baked into the screenshot deliberately on our side: our layer is hidden from screen capture, so we draw it onto the frame ourselves when it is open. You said the menu was already toggled off, so that is a different case - for that one I need the file name from the log and the image that came out.

Thank you for the detail you put into this; the log and the video made both real bugs visible, and one of them has a number I can act on.

[raycornea]

Bugs details:

• "HDR -> SDR: 18.6 seconds, not endless" : the screen had the full screen gray overlay + moving blocks animation (the one used when changing settings or restarting some app processes). "Endless" meant that i waited about 30 seconds then closed it via Cltr+Alt+Q, as there was no visual progression of this process finishing (these loadings never take longer then 1-5 seconds).
  *After some testing, this happened upon turning OBS option on, yet the loading screen effect disappeared when toggling NR On/Off
• "The panel appearing in a screenshot" : it should be in the existing log, all taken screenshots had the app in them, altough some had full black background (as seen above), while the others have the screen + app overlaying.
  *After some extra testing : this only happens on the 2'nd display, and it seems to be because of the auto app disappear upon toggling NR On via shortcut or in app button click. I tried recording this, yet the recording process just get's cut off when i toggle NR on off and this happens.
• "The menu after NR on, and the cursor moving" : i tried recording via app recording and OBS (in which the app doesn't appear), yet it is not captured, only via external video recording (attached bellow).

Extra feedback:

• higher lag upon toggling NR On/Off : i know it's probably because of the recent fix to fully turn NR off, just wanted to let you know. (previous instant, no lag, now has about 2-4 sec lag upon turning on while in-game).

Suggestion (more of my personal taste, can be ignored)

• If possible a toggle/option for previous desaturated color scheme (from version 1.6) with exposure correction. In some setups, that one seems to bring more realism/depth (ex: some sci fi games like Endfield).

I'm glad i can contribute to this project and thank you for the fast replies

Log
NeuralScreen.log

Bug "The menu after NR on, and the cursor moving"
https://github.com/user-attachments/assets/a73e0c47-30aa-43b9-843b-3b1029e6c1b4

[perseval-BLR]

v1.14.0 is out: NeuralScreen v1.14.0

The flicker: fixed, and your log is what made it a one-line diagnosis

You were right that the fix had to be in the request, not in the rebuild. The single-format request you asked me to look at is what shipped.

Your log showed the shape of it exactly: with HDR compatibility on, DuplicateOutput1 was given a list of two formats (FP16 first, BGRA8 second) and the driver alternated between them - 1,955 rebuilds in 2.5 minutes. The same log showed which half was stable: 0 flips for the rest of the session on the FP16 path.

So the capture now pins the format instead of offering a choice. On a display that can produce a high-colour surface, the capture takes the FP16 path itself and converts to SDR in the shader - which is what your own log already showed happening (capture=FP16 (10-bit output) - presented as SDR). HDR compatibility still governs what you see; it no longer decides what the capture asks the driver for.

One detail from your log decided the condition. The line is:

[dda] output colour space 12, 8 bits per colour - HDR IS ON for the captured display

An HDR-capable display reports 8 bits per colour, so a bit-depth test would have missed your TV entirely. The trigger is the display's own capability. An 8-bit display keeps exactly the path it had.

What I cannot confirm, and need you for. This bench has an 8-bit display, so I can reproduce your case only from your log, not live. The fix is verified by the code path, by the worker compiling and running, and by the 8-bit path behaving identically to before - but the HDR-off TV retest is yours to make. If it still flickers, the log line to look for is [dda] 10-bit scan-out: FP16 duplication pinned through IDXGIOutput5 (no format flips); if you instead see FP16 duplication refused ... falling back to legacy SDR, the driver refused the single format and I want that log.

While fixing it I found one of my own bugs

The first version of this fix left the DXGI output reference released only inside one branch, while it is acquired on every path. On your display - and on any 8-bit one - that reference was never released. No symptom you would have seen, but it is fixed in the same release, and there is now a test that counts the acquisitions against the releases.

The HDR -> SDR switch

Your log settles what was on screen during the 18.6 s, and it is a case I fixed in this release. The sequence is:

[main] NR OFF
21:13:18.469  [present] overlay closed; results go back to the client
[main] NR OFF: capture, processing and presentation suspended
[main] monitor change: 1 -> 0
[main] switch overlay ON (layer 3840x2160 -> 1920x1080, frame=none)
21:13:37.057  [host] adapter 0: NVIDIA GeForce RTX 5080 ...

The assembling mark was raised at the monitor switch while NR was off, so the pipeline was suspended. With NR off our main loop takes the low-cost branch, which never receives a frame - and it is a received frame that used to take the mark down. Nothing was coming, so the mark stayed up, exactly as you described it, with no progress and no way out but a restart. That is the bug this release fixes: the idle branch now takes the mark down itself.

To be exact about what this does not fix: those 18.6 s are also the new worker starting up, and that part stays. What changes is what you see - the mark goes away at once instead of holding the screen for the whole start. If the wait itself bothers you after the retest, that is a separate one to look at.

Still open from your report

Two things from your v1.13.1 message are not in this release, and I do not want to leave them looking fixed:

• The black screenshot with NR off. You are right about the mechanism: with NR off the pipeline is suspended, a screenshot brings it back for one frame, and that frame is saved before a processed picture has returned. Confirmed from your JPEGs and the log. Not fixed yet.
• The panel appearing in screenshots on the second display after NR on/off.

The auto-menu-off option you asked for is a fair request; it is not in this release either.

The lag when toggling NR on/off is the price of the real OFF from v1.13.0 - the worker now stops and starts rather than idling. I would rather keep the OFF honest than hide it behind a faster path that only looks off.

[raycornea]

Thank you for the fast fixing, here is my feedback on the new version

Fixed:

• "The flicker" : there is no longer any flickering on the 2'nd display
• "What changes is what you see - the mark goes away at once instead of holding the screen for the whole start" : yes, well the bug was mostly about loading screen not disappearing. I tested my scenarios and this whole issue is completely fixed
• Variable framerate seems somewhat fixed, they are mostly above 70 now, sometimes going below 40 (on faster movement).

Bugs:

• "The menu after NR on, and the cursor moving" : still exist
• [new] Screenshot dialog afterimage seen (attached below)

Notes:

• "auto-menu-off option" : this was a bug rather then a feature (which i wrongly assumed), happening on 2'nd display only upon activating NR.
• "The lag when toggling NR on/off is the price of the real OFF" : i agree, yet if possible, a toggle option to have fast loading/NR or full Off would be a nice customization addition.

Log
NeuralScreen-diagnostics-20260918-005626.zip

Bug "The panel appearing in screenshots on the second display after NR on/off" + "screenshot with invisible app menu" + OSD keys display in the corner ([1] = Num1 , and so on ..)
https://github.com/user-attachments/assets/27c44fb8-fdcc-4ade-bf0d-95d501a51691

[perseval-BLR]

Thanks - the flicker, the veil and the fps numbers are good news to hear.

Your log helped me narrow the two remaining screenshot items, and I need one detail from you for each.

The panel in the screenshot. You wrote that the menu was already toggled off. In your v1.14.0 log both screenshots were taken with the capture running normally, so I cannot tell from it whether the panel was open at that moment. Could you say, for one shot that came out with the panel in it: was the settings panel visible on screen when you pressed the key? If it was not visible on screen and still ended up in the file, that is a real bug and I want it.

The screenshot dialog afterimage. Same question: does the dialog box itself appear in the saved image, or does the file look right and the afterimage stays on screen afterwards?

Both are about the same thing on my side - the frame is frozen before the dialog opens, and the menu is drawn into the frame only while it is open - so a yes/no on "was it visible at that moment" decides which of the two is happening.

The black-background case you sent earlier is already understood and is a separate one: with NR off the pipeline is suspended, and the screenshot brought it back for a single frame that had no picture yet. That one is on my list.