pxpipe Sol RGB 通道分离诊断：三路文字叠加到同一张图片，为什么模型读不出来？

【免费下载链接】pxpipecut Claude Code token usage by rendering text context as images项目地址https://gitcode.com/gh_mirrors/px/pxpipe点击查看免费下载本篇文章围绕 pxpipe 评估目录中的RGB_SEPARATION_RESULTS.md展开完整还原一次针对gpt-5.6-sol模型的三通道 RGB 叠加渲染对照诊断同一张 PNG 被拆成十个对照臂结论是单通道提取全部健康最高 12/12而三路叠加后精确读取归零0/12~1/12问题出在模型视觉处理对重叠字形的合并而非渲染器本身。读完本文你将理解 pxpipe 如何用受控诊断隔离变量、验证一个渲染假设是否成立以及为什么这套 RGB 复用方案最终被研究性保留、未进入生产运行时。为什么 pxpipe 会尝试 RGB 通道叠加渲染pxpipe 的核心思路是把文本上下文渲染成图片再交给视觉模型读取从而压缩 token 用量。既然已经证明图片上下文可行一个自然的激进想法是PNG 有红、绿、蓝三个颜色通道如果能把三行文本分别写进三个通道同一张图就能携带三倍的信息量进一步压缩输入成本。在这个思路下仓库里先后出现了两个被标记为 rejected 的研究臂eval/sol-profile/novel-arithmetic-jbmono12-rgb-results.json被拒的 RGB 算术臂eval/sol-profile/gist-recall-jbmono12-rgb-rbg-results.json被拒的红→蓝→绿逐行顺序臂。更早的整图评估结果已经给出负面信号见 QUALITY_RESULTS.md交替 RGB 配置下 gist 只有 58/98、状态跟踪 11/18、守卫幻构 10/16完整红→绿→蓝通读更差gist 36/98、状态 5/18。但这类结果无法回答一个关键问题到底是叠加这一步破坏了可读性还是单通道本身就读不出RGB_SEPARATION_RESULTS.md记录的正是为回答这个问题而设计的受控对照实验同一张叠加图人为把各通道单独提取出来与原始叠加图放在同一套提示词与打分标准下对比。实验设计同一张 PNG、十个对照臂诊断脚本是 rgb-separation-diagnostic.mjs模型为gpt-5.6-sol可通过SOL_QUALITY_MODEL覆盖走 OpenAI-compatible/v1/responses直连通道不经过 pxpipe 自身。测试数据脚本生成 36 条逻辑行格式为L01 wordamber code04729这样的标签行其中code是 5 位确定性伪随机码const logical Array.from({ length: 36 }, (_, i) { const code String((i * 7919 104729) % 100000).padStart(5, 0); return L${String(i 1).padStart(2, 0)} word${words[i]} code${code}; });36 行按行号模 3 分配到三个通道每通道恰好 12 行i % 3 0走红色、i % 3 1走绿色、i % 3 2走蓝色。单张combined.png尺寸为 768×190 像素、8654 字节见 rgb-separation-diagnostic-results.json 的image字段所有臂共用这一张图。十个臂类别臂提示词要点叠加通读combined该图在 RGB 通道中叠加了三路独立文本流每行先读 RED 再 GREEN 再 BLUE返回 keys 为 red/green/blue 的 JSON每个值为按阅读顺序的 12 条精确行单通道提取red-color/red-white/green-color/green-white/blue-color/blue-white读取唯一可见的文本流返回按从上到下顺序包含全部 12 条精确行的 JSON 数组叠加聚焦combined-focus-red/combined-focus-green/combined-focus-blue忽略其他所有颜色只读叠加图中 X 通道的文本流返回按顺序包含其 12 条精确行的 JSON 数组打分规则非常严格模型返回的 JSON 数组中的行必须与预期行逐字符完全相等才算命中脚本中score()对expectedLines.filter((line) got.includes(line))计数。文档把combined加六个提取臂称为完整的七臂诊断三个聚焦臂用于验证即使显式命令只读某一颜色是否可行代码里在 live 模式下总是追加执行也可以用RGB_FOCUS_ONLY1单独运行。渲染器与通道提取的像素级原理RGB 叠加渲染器rgb-multiplex-renderer.mjs 是 eval-only 的 JetBrains Mono 12px RGB-overprint 渲染器。它注册仓库内置字体assets/JetBrainsMono-Regular.ttf字体族名PxJBMono12RgbResearch核心几何常量是const FONT_PX 12; // 字号 const CELL_W 8; // 单元格宽 const CELL_H 13; // 单元格高 const ASCENT 11; const PAD 4; const CHANNEL_COUNT 3; const BANNER_ROWS 2;渲染分两步先画三张独立字模遮罩为红/绿/蓝各创建一张黑底画布把同一物理行对应的三条逻辑行分别用白色文本绘制到对应遮罩上。也就是说每 3 条逻辑行共享 1 个物理行红色取第row*3行、绿色取row*31行、蓝色取row*32行基线完全相同——这正是字形碰撞的根源三条文本在物理空间上完全重叠。逐像素合并三张遮罩的 RGBA 数据按通道取位最终像素为R←mask0 的 R、G←mask1 的 G、B←mask2 的 BAlpha 恒为 255rgb.data[i * 4] maskData[0][i * 4]; rgb.data[i * 4 1] maskData[1][i * 4]; rgb.data[i * 4 2] maskData[2][i * 4]; rgb.data[i * 4 3] 255;页面上方还会画两行横幅提示RGB OVERPRINT: EACH ROW READ RED GREEN BLUE; THEN NEXT ROW。默认cols95、maxHeightPx1932与 Sol 生产配置一致宽度为2*PAD cols*CELL_W 768。单通道提取提取臂不是重新渲染而是从同一张 combined.png 解码后反向取通道这正是同一张 PNG 用于所有臂的保证用getImageData读出源像素后value source[i*4channel]再分两种模式写出color模式只有目标通道保留亮度其余通道置 0形成纯红/纯绿/纯蓝文本white模式三个通道都写入该亮度值即把提取结果转换成白字黑底。由此单通道臂与叠加臂之间唯一变量就是是否发生字形叠加其余字体、几何、压缩、传输完全相同。结果单通道健康叠加后归零下表完整继承自 RGB_SEPARATION_RESULTS.md与 rgb-separation-diagnostic-results.json 中逐臂的exact/total完全一致armexact linesextracted red channel, red12/12extracted green channel, green11/12extracted blue channel, blue11/12extracted red channel, white11/12extracted green channel, white11/12extracted blue channel, white10/12combined RGB, return all streamsred 0/12; green 1/12; blue 0/12combined RGB, focus only red0/12combined RGB, focus only green1/12combined RGB, focus only blue0/12几个值得注意的数据细节提取臂几乎满分红色原色提取 12/12绿/蓝也达 11/12。PNG 编码器、各通道数据本身、12px JetBrains Mono 字形在小尺寸下的可读性都被证实是健康的。白化没有帮助把提取通道转成白字黑底red-white等后分数不升反降蓝色从 11/12 降到 10/12说明通道纯度不是瓶颈。叠加臂全军覆没combined全量通读三通道仅绿 1/12三个聚焦臂在显式忽略其他颜色、只读 X 通道的指令下依然是 0/12 与 1/12。错误形态是融合而非漏读从 receipt 的原始返回看叠加臂输出的并非缺失或空白而是一批融合变体——例如聚焦红色臂返回L02 wordcynch code20648、L05 wordenote code26405、L11 wordkermite code93090、L35 wordhyral code730756。这些词既不在红色层也不在任一单一层中而是多个通道字形按笔画碰撞后拼出的混合体且code数字也发生了串位与增长如730756超过 5 位。成本数据叠加通读臂输入 233 tokens / 输出 399 tokens、耗时约 8s提取臂输入 203 tokens、输出约 130 tokens聚焦臂输入 214 tokens。整套诊断消耗极小属于受控的少量付费调用。结论与归因RGB_SEPARATION_RESULTS.md的结论可以拆成三层渲染链路健康PNG 编码器与每个颜色通道都没有问题没有任何一个通道天生更差红 12/12绿蓝 11/12。白化转换无效提取通道转白字黑底不能提升分数可排除颜色亮度或对比度干扰。失败点在三张字模叠加之后gpt-5.6-sol无法可靠地从合并后的 RGB 平面里分离出单一通道即使在语言层面明确命令忽略另外两种颜色。这不是当前渲染器的红/绿/蓝顺序或亮度问题而是重叠字形碰撞在模型的视觉处理阶段先被合并语言级指令无法在事后恢复它们。换句话说单通道信息进得去、读得出但三通道信息叠加后模型看到的是字形笔画融合后的整体图形而不是可分离的三个图层。如何复现与重跑诊断脚本需要先构建它从../../dist/core/gpt-model-profiles.js导入resolveGptProfile来解析gpt-5.6-sol的渲染画像pnpm run build # 本地渲染 写出 receipt不产生任何模型费用rows 为空 node eval/sol-profile/rgb-separation-diagnostic.mjs只有显式设置SOL_QUALITY_LIVE1才会真正调用模型responses-client.mjs 会读取OPENAI_API_KEY并请求OPENAI_BASE_URL下的/responses端点SOL_QUALITY_LIVE1 node eval/sol-profile/rgb-separation-diagnostic.mjs # 只运行三个 combined-focus 聚焦探针 SOL_QUALITY_LIVE1 RGB_FOCUS_ONLY1 node eval/sol-profile/rgb-separation-diagnostic.mjs可用环境变量SOL_QUALITY_MODEL默认gpt-5.6-sol、RGB_FOCUS_ONLY1时跳过 combined 与提取臂、SOL_QUALITY_TIMEOUT_MS默认 180000ms。叠加通读臂maxOutputTokens1600其余臂为 700。输出目录为.work/rgb-separation-diagnosticreceipt 固定写入rgb-separation-diagnostic-results.json。值得注意的安全设计客户端会拒绝 pxpipe 自身的监听端口 47821确保评估输入不会被 pxpipe 二次变换实验测的是原图直读而非pxpipe 处理后的图。对生产配置的影响这套 RGB 研究与结论最终被明确拒之于生产之外见 QUALITY_RESULTS.md 的 RGB-overprint research (rejected for production) 小节不发布任何 RGB 代码或字体图集rgb-multiplex-renderer.mjs标注为 eval-only生产运行时中不存在rgbMultiplex相关配置路径在 src 目录搜索rgbMultiplex无命中。Sol 保持 opt-in 且默认关闭据 README.mdgpt-5.6-sol的正式画像已改用原生 JetBrains Mono 14px、9×16 网格、84 列需通过 dashboard 或显式PXPIPE_MODELSclaude-fable-5,gpt-5.6-sol启用生产基准中 5×8 Spleen 画像的图片臂算术 98/100、gist 83/98、状态跟踪 17/18但密集 12 字符十六进制 0/15且匹配算术场景图片输入 tokens 比文本高 32.1%说明短提示词场景下图片并非压缩赢家。本文诊断的定位是研究记录RGB_SEPARATION_RESULTS.md、渲染器与 receipt 被保留用于后续研究结论为 RGB 三通道复用这一方向的探索画上了阶段性的句号——问题不在像素合成而在模型视觉系统对叠加信息的融合能力。对于任何想在类似项目里做多路图片信息复用的工程师这份诊断提供了一个可复用的方法论先用受控的单通道提取臂验证渲染链路再叠加变量观察模型行为边界并用精确整行匹配代替宽松关键词来打分这样能干净地把渲染问题与模型能力问题区分开。赞分享【免费下载链接】pxpipecut Claude Code token usage by rendering text context as images项目地址https://gitcode.com/gh_mirrors/px/pxpipe点击查看免费下载相关推荐为什么音乐加载不出来Webamp的CORS跨域问题快速诊断与解决方案为什么音乐加载不出来Webamp的CORS跨域问题快速诊断与解决方案 Webamp 是一个将经典 Winamp 2 播放器重新实现于浏览器的开源项目让你网页前端音视频pxpipe GPT-5.6 Sol 原生字号扫描全记录为什么 14px/9×16 成为唯一可用渲染档位pxpipe GPT 5.6 Sol 原生字号扫描全记录为什么 14px/9×16 成为唯一可用渲染档位 本篇技术指南基于 pxpipe 仓库中 eval/sOpenRGB究竟能为你带来什么一文读懂开源RGB控制的神奇魅力OpenRGB究竟能为你带来什么一文读懂开源RGB控制的神奇魅力 还在为不同品牌的RGB设备安装各种臃肿的厂商软件而烦恼吗OpenRGB作为一款完全免费开源桌面应用硬件开发智能硬件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考