Repository navigation
+ derived specification of what differs between the xBRZ releases - #22
Merged
Merged
Conversation
Rung 2 of the re-use ladder: xBRZ is GPL-3.0 and this library ships LGPL, so the releases were read to build material rather than copied. This is that material - a description of the behaviour, written so an implementation can be produced from it and checked, containing none of Zenju's code. Two of the three suspected gaps turned out not to be gaps at all. "Center direction bias", added in 1.7, only made a hard-coded factor of 4 into a configuration field whose default is also 4; this implementation already uses 4 for that term. The asymmetric colour distance fixed in 1.7 came from packing channel differences into a byte-indexed lookup table, which this implementation never used - it calls a colour metric directly, so distance was always symmetric. The existing entry is therefore 1.7-equivalent and needs no version suffix. 1.8 makes the area outside an ARGB image transparent. That decision is already exposed here per axis as OutOfBoundsMode, so a 1.8 variant would duplicate an existing knob. That leaves 1.9, which differs twice over: the steep direction threshold moves from 2.2 to 2.4, and the weighted blend rounds to nearest where it used to truncate. ColorLerpInt truncates today, so both are real.
This was referenced Sep 21, 2026
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
1 participant
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.
Groundwork for Hawkynt/2dimagefilter#30 ("xBRz implementation out of date"). No behaviour change — this adds the derived material the implementation will be produced from.
Why a document and not a patch
xBRZ is GPL-3.0 and this library ships LGPL-3.0-or-later, so it sits on rung 2 of the re-use ladder: read the source to build a specification, a set of test cases and an oracle, then implement from that material. Not copy it, not transliterate it. This is that material. It contains none of Zenju's code — only a description of behaviour, with provenance recorded.
What reading the releases actually showed
The issue says the implementation is out of date. It is, but far less than it looks, and not where I first thought. Three suspected gaps, two of which are not gaps:
centerDirectionBias(1.7)4into a config field defaulting to4.Xbrz.csalready uses4for that term.+46unpacked as45,-46as-47). This port calls a colour metric directly and never had it.OutOfBoundsModealready exposes that per axis, configurably. A 1.8 variant would duplicate an existing knob.So the existing
xBRZentry is 1.7-equivalent and should keep its name — no version suffix, so existing scripts and saved settings keep working.What is genuinely missing: 1.9
Two exact, integer changes, both real here:
x * 22 <= y * 10; 1.9 is* 24. Ten sites — the shallow and steep test in each of the five scale kernels.ColorLerpIntdoes(a.C1 * w1 + b.C1 * w2) / total, which truncates, matching pre-1.9.Both re-verified against this branch's base after rebasing onto current
main.Open design question, deliberately not decided here
ILerpis chosen by the pipeline, not by the scaler, so a 1.9 variant cannot simply select a rounding lerp. Either a rounding counterpart toColor3BLerpInt/Color4BLerpIntthat the 1.9 path picks, or rounding inside the xBRZ kernels. The first is more correct, the second less invasive to an interface used well beyond xBRZ. Noted in the document rather than settled unilaterally.Verification
2dimagefilterbuilds and its 665 tests pass against this branch, so nothing here disturbs the consumer.