OpenSurface Camera Obscura: Guided Detail Reclamation and Guided Ink Lines

  • dastardlyrat
  • Topic Author
More
2 weeks 4 days ago - 2 weeks 4 days ago #1 by dastardlyrat OpenSurface Camera Obscura: Guided Detail Reclamation and Guided Ink Lines was created by dastardlyrat
The goal is not maximum effect. The goal is a shader that can explain why it acted.

OpenSurface Camera Obscura: Guided Detail Reclamation and Guided Ink Lines

This is the first public staging pass for the OpenSurface Camera Obscura shader work.

The package contains two ReShade effects:

- Guided Detail Reclamation
- Guided Ink Lines

Both are built around the same idea: do not just react to contrast. First ask whether the pixel has enough surface support, depth confidence, and local evidence to deserve action.

Guided Detail Reclamation is not meant to be a generic sharpener. It recovers local detail with a capped signed lightness contribution, so it can brighten or darken small same-surface detail without trying to redraw the whole image.

Guided Ink Lines is not meant to be a blunt outline pass. It builds ink from stable edge evidence, fine detail evidence, object contour carry, and optional surface-support outlines. It only darkens, and it includes debug views so the user can see what is being admitted before trusting the final composite.

The important part here is inspection. The effects expose the control path instead of hiding it. You can look at reuse readiness, depth confidence, neighbor coverage, surface support, masks, applied contribution, contour fields, and final output as separate views.

The current public repo is here:

github.com/dastardlyrat/OpenSurface-CameraObscura-GuidedDetail

This is an early public staging release. It is intended for compile testing, visual testing, tuning feedback, and documentation cleanup. The code is intentionally small: two effects, two local headers, and no bundled ReShade framework files.

What I am looking for:

- clean compile reports
- screenshots of useful or broken debug views
- cases where surface support behaves well
- cases where surface support bands, crawls, or over-admits
- tuning notes for different games and depth buffers

If you test it, please check the debug views before judging the final image. The final composite can look subtle while the debug views reveal whether the rail is healthy.

Suggested first inspection order:

1. Reuse Ready
2. Depth Confidence
3. Addressed Neighbor Coverage
4. Surface Support
5. Mask / Field view
6. Applied contribution
7. Final Composite

-Bug Collective: rat, maufus, alia, verminis
 
Last edit: 2 weeks 4 days ago by dastardlyrat. Reason: copy paste error

Please Log in or Create an account to join the conversation.

We use cookies
We use cookies on our website. Some of them are essential for the operation of the forum. You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.