feat(pixel-grid): add independent native grid detector - #493
Conversation
Pixel-style images need a reusable grid estimate before reconstruction can run. Port the fixed upstream consensus detector behind bounded PNG/JPEG bytes and a six-field JSON CLI. The detector now runs independently without importing the application or generation pipeline.
The native detector needs a reproducible package boundary and dependency graph. Add the Rust manifest, locked dependency set, and local target exclusion. The module can now be built in isolation with deterministic dependency resolution.
The detector contract needs evidence for both simple grids and disputed inputs. Cover arbitration, sub-three-pixel confidence, JSON fields, and bounded encoded input. Regressions in consensus execution or resource handling now fail at the module boundary.
The reused detector must remain reviewable and license compliant. Document the standalone CLI, capability boundary, fixed upstream revision, and MIT terms. Maintainers can trace both the algorithm and its arbitration fixture to their source.
The standalone native module needs a gate that does not widen backend CI. Run format and locked release tests only when detector paths or its workflow change. Detector changes now receive isolated validation without touching generation jobs.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
![fennoai[bot]](https://avatars.githubusercontent.com/in/1924301?s=60&v=4){kind=small}
There was a problem hiding this comment.
已完成对固定 0b1e5acd6fa62988dff453161cb09773ecdc0731...baa1eb679134341f3a5d8397d24f99e8aec76f21 完整变更范围的审查，覆盖 CI path filter、Rust crate 边界、PNG/JPEG 解码与资源限制、full/fast 检测路径、六字段 JSON 契约以及测试 fixture。未发现满足审查标准的可操作 P0–P3 正确性、可靠性、安全性或性能问题。
验证：远端 PR checks 中 test、lint-and-test、codecov/patch 均通过；固定 diff git diff --check 通过。当前审查环境未安装 Cargo，因此未在本地重复运行 Rust 测试。
xiaocheny214
left a comment
xiaocheny214
left a comment
There was a problem hiding this comment.
@huyanxius 这是rust语言吗？虽然rust语言性能很高......但这怎么接入后端是python语言的项目中？这个对外提供的api接口我也没有看到👀
api 接口我特地没定，交给你们后端来定吧
目前决定采用PyO3 原生扩展，Rust 源码仍放仓库根目录 native/pixel-perfect，不放进 Python backend；通过 maturin 编译成 Python 可导入的原生模块，后端只保留调用适配层 |
The detector is a native algorithm library rather than Python backend code. Move the crate into the root native workspace and remove the retired CLI boundary. Keep the detector independently buildable for the later PyO3 binding.
The detector CI still watched the retired backend-native path. Point path filters and the working directory at the root native workspace. Detector checks now run for the relocated crate.
huyanxius
changed the title
|
这个问题成立，已按评审调整边界：Rust 检测器已从 |
A shared workspace would couple later pull requests before their merge order is established. Keep the detector lockfile with its crate and remove the premature workspace manifest. Each native module can now build and land independently.
The detector no longer builds through a shared native workspace. Run its workflow from the crate directory with the crate-local lockfile. CI now matches the independently reviewable module boundary.
xyh202131
left a comment
xyh202131
left a comment
There was a problem hiding this comment.
已复核当前提交：原生像素网格检测器保持独立库边界，输入大小、像素量与解码资源限制明确，六字段检测契约和 full/fast 路径均有测试覆盖；当前 CI 全部通过且无未解决审查线程。
|
这是在做什么？看起来对架构有极大的调整？ |
结论这条 PR 不是在迁移或重构现有 Windup 架构，而是在仓库根目录新增一个目前完全隔离的 Rust library，作为后续像素重建能力的底层检测组件。
看起来“架构调整很大”的主要原因是算法本身被完整拆成了多个 Rust 模块，共新增约 4,879 行、21 个文件；这些代码主要是 Pixel Art Fixer 的多检测器共识算法及 Windup 的输入边界封装，不代表应用层被重写。 后续真正的集成点后续 #492 才会提供 PyO3 binding 和工具 API，届时才会把这个 Rust crate 接到 Python/应用侧；#491 则负责网格重建。换句话说，这个 PR 更像是先把“检测内核”单独落地，刻意避免现在就扩大生产架构的耦合面。 我也按 PR 指定的固定提交范围 |
@minorcell 这个是新增了一个完美像素化的检测模块，刻意没有动架构，但是按照和导师讨论需要把完美像素化接入生成像素风格的生成管线，所以这里架构会有一个变动 |
结论明白了：当前 PR 是先落地“完美像素化”的检测内核，后续再把它接入生成像素风格的管线。所以你说的架构变动是预期中的下一阶段变化，但不发生在这条 PR 的当前差异里。 我按固定提交范围 推荐的接入分层后续接入时建议保留下面的边界，而不是让 Rust 检测算法直接依赖生成管线：
这样架构确实会新增一条处理链，但属于新增适配器和生成阶段，不是把现有后端整体迁移到 Rust。建议后续 PR 把“是否启用完美像素化”和“检测/重建失败时的 fallback”作为显式配置，避免默认改变所有图片生成行为。 对这条 PR 的判断因此我会把 #493 理解为一个合理的基础设施 PR：先建立可独立测试、可替换的检测契约；真正需要重点评审架构影响的是后续 #491/#492 以及生成管线接入 PR，包括调用位置、任务耗时、失败降级和结果缓存。 |
@huyanxius 如果按 #489 这里的结论，我们应该不需要一个“grid detector”模块？因为目标分辨率是已知的 |
我觉得这个可能得做一下测试？因为图片生成模型很可能并不会按照我们目标像素生成，所以这里的grid detector我觉得可以作为一个检测工具校验模型输出是否符合已知目标网格，否则如果： |
@huyanxius 这个是大概率会发生的。只是即使我们检测了，我们也没法基于检测结果做什么？ |
对，但是可以根据生图模型实际的像素来进行完美像素化……不过好像无济于事，因为他不是项目约束了 |
@huyanxius 以上面具体的 256x256、32x32 为例，如果用户指定了 32x32，即使图片生成模型遵循得不好，我们给他 32x32 也要比给他 256x256 更好。 32x32 的问题是生成的图片遵循不好导致在降分辨率后人物形象的识别率低，但不是完全不可用 而 256x256 的问题是，在游戏中实际渲染时
可以看到，不管哪个情况，256x256 都不会比 32x32 更好。
如果不是项目要的像素密度，那它就不是“完美像素”的。如果用户对这个的预期是 32x32，那么我们自动识别并处理后的 256x256 并不会比原图（如 1024x1024）更符合用户需求 |
ok，那这个 PR 关了吗？这样看来就没有grid detector的必要了 |
|
在 21 张人工标注为像素画的真实生产母版上量了隐含网格：逻辑高 4 |
@johnnyzhang-eng 没理解，每张的“隐含网格”不同为什么会导致不知道怎么采？图片原分辨率我们是知道的，目标分辨率我们也是知道的，那降分辨率的采样行为不就是确定的吗？ |
嗯，我没问题 |
|
根据讨论，不再引入grid detector，PR 关闭 |
6 participants
新增独立 Rust 像素网格识别库，为后续 PyO3 工具 API 提供稳定的六字段检测契约；算法源码位于仓库根目录，不属于 Python 后端，也不进入任何生成或工作流调用链。
Why
模型生成的像素风图片通常仍存在隐含网格、抗锯齿和非整数像素单元。重建模块需要先获得可替换、可验证的网格估计，同时 Rust 算法不应被归入 Python 后端目录或通过生产 CLI 暴露。
Changes
cols、rows、step_x、step_y、consensus、confidence。<3px时统一标记为低置信度。native/pixel-perfect/crates/detector/，删除生产 stdin/stdout CLI 和 JSON 依赖。Implementation
detect_bytes是唯一算法入口，DetectorMode::Full与DetectorMode::Fast保持显式区分。Verification
cargo fmt --check：通过。cargo test --release --locked：5 项测试通过，0 项失败。git diff --check upstream/main...HEAD：通过。Scope
<3px的自动识别准确率，不加入单图启发式特例。Related Issues
Closes #490
Refs #489