Repository navigation
+ xBRZ 1.9 is offered alongside the existing xBRZ entries - #57
Merged
Merged
Conversation
The upstream rescaler registry gained an "xBRZ 1.9" entry, which reaches the GUI and the command line on its own because the manipulator list is built from that registry rather than from a hand-maintained table. Nothing here had to change to expose it, so this records it and pins it. 1.9 raises the steep direction threshold and rounds its blends instead of truncating them; the plain xBRZ entries are untouched and still produce exactly the pixels they always did, which is what keeps existing scripts and saved settings working. The new test asserts both families are offered at every scale, so an upstream change that renamed or replaced the existing entry rather than adding beside it would fail here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #30, together with Hawkynt/C--FrameworkExtensions#23, which carries the implementation —
Xbrz.cslives upstream.What changed upstream
xBRZ 1.9 made two changes to the output, both exact and integer: the steep direction threshold rose from 2.2 to 2.4, so fewer near-diagonal runs are treated as lines, and the weighted and 50/50 blends round to nearest rather than truncating.
1.5 through 1.8 were not gaps, which is worth stating because they look like they should be. 1.5 and 1.6 changed only the API and performance. 1.7's "centre direction bias" turned a hard-coded
4into a config field defaulting to4, and its asymmetric colour distance came from a byte-indexed lookup table the port never used. 1.8's transparent-outside-area rule is already reachable per axis throughOutOfBoundsMode.What changed here: nothing in the product code
The manipulator list is built from the upstream rescaler registry rather than a hand-maintained table, so the new
[ScalerInfo("xBRZ 1.9")]entry reaches both the GUI and the CLI on its own asUpscaler: xBRZ 1.9 2x…6x. This PR records that in the README and pins it with tests.The existing
xBRZentries are untouched and bit-identical — upstream pins their output by hash against what they produced before 1.9 support existed. That is what keeps existing scripts and saved settings working; 1.9 is a separate entry, following theXBR/XBR NoBlend/XBR 3x Originalprecedent, rather than a change to the existing one.Verification
SupportedManipulatorsTests.BothXbrzReleasesAreOfferedSeparatelyasserts both families are offered at every scale from 2x to 6x, so an upstream change that renamed or replaced the existing entry rather than adding beside it fails here rather than silently reaching users.CommandLineEndToEndTestsgainsUpscaler: xBRZ 1.9 4x, which drives the new scaler end to end through the CLI.665 → 667 tests, green.