RGBV3D 容器格式

为什么还要一个无损格式？

日常无损互通早已有 PNG。RGBV3D 定位是研究与教学容器：比特流小而可审计，便于演进（块级 triage、熵编码、可选多帧），并不假装一夜取代 PNG。PracticalKit 提供浏览器编码器与长文说明，方便审核者与协作者先看行为再装私有工具链。

今天保证：标注无损的 profile 上，decode(encode(pixels)) 等于送入编码器的 RGB24。不保证：任意图都比 PNG/WebP 小、手机上流畅编数百万像素照片、或超出浏览器 canvas 的专业色彩管理。

Profile 0 — classic（lossless-rgb）

Classic 走空间预测 + Deflate 残差流，思路接近 PNG：吃掉局部相关，存下不可预测部分。魔数、块布局与 profile id 独立，避免与 PNG 混淆。@rgbv3d/core 单测覆盖纯色、渐变与合成噪点的像素级往返。

当 classic 输给 PNG，往往因为 PNG 预测器与过滤器经过多年边角硬化。把 classic 当作 RGBV3D 的保守路径——尤其噪点输入——而不是体积竞赛。

Profile 1 — vector-v2

Vector-v2 把像素 C=(R,G,B) 分解为模长 L 与第一卦限码本上的方向 d。编码器存方向索引与量化范数代理 ΔLq，再写逐通道残差以保证精确重建。没有残差时，低比特方向 alone 无法无损——两个不同 RGB 可能落入同一方向桶。

平滑 UI 面板与合成渐变常受益：邻居共享方向，残差小。高 ISO 颗粒与抖动扫描则相反：残差逼近全通道熵，体积膨胀。失败场景写在 benchmark 页，而不是藏起来。

文件结构

文件以魔数、版本、宽高、profile id 开头，随后是各压缩流（适用时的方向、可选 sign 占位、ΔLq、残差）。阅读器须拒绝未知的关键版本。实验性多帧容器 .rgbv3dvi 按帧堆叠载荷并带时序元数据；帧间预测仍在路线图，不可假设今日 CLI 已默认开启。

如何证明无损

CI 对编解码前后的 RGB buffer 做哈希。浏览器用户可解码后导出 PNG，用 ImageMagick 或短 Python 脚本 diff。断言「差异像素为零」，不要只说「看起来一样」。色彩描述文件被剥、canvas 预乘 alpha 是常见误报——整条管线保持宽高与 alpha 策略一致。