Lossless claims require evidence. Our recommended workflow for skeptics and integrators:
1. Start from a PNG master with known dimensions and no alpha surprises (flatten if needed).
2. Encode to .rgbv3d in the browser tool or via CLI, record profile and file size.
3. Decode back to RGB24 buffers, export PNG from the image tool or CLI.
4. Diff with imagemagick compare, Python (PIL + numpy), or your CI harness.
What to assert: zero differing pixels, not “visually identical.” Histogram-only checks miss single-pixel edge drift. For large frames, diff in tiles to avoid loading entire rasters twice in memory.
Common false alarms: color profile stripping, premultiplied alpha, and browser canvas color space conversions. Rasterize consistently—same source file, same width/height. If you resize in between steps, you are testing a different pipeline.
Automating in CI: store small golden PNGs in fixtures, run encode/decode in Node with @rgbv3d/core, hash the output buffer with SHA-256. Our hash tool page complements this but image hashes should be on raw RGB bytes, not PNG re-exports with different compressors.
When diff fails, capture intermediate .rgbv3d and file an issue with profile, dimensions, and the first failing coordinate. That feedback improves triage heuristics more than anonymous “doesn’t work” reports.
Linking to site tools: /rgbv3d/ for encode/decode, /image/ for PNG export, /hash/ for digest checks, /rgbv3d/format/ for bit-exact field definitions. This end-to-end story is unique content— follow it once and you understand the codec better than reading ad copy.
Split verification into human spot checks and automated gates. Spot-check one UI capture and one noisy photo in the browser tool with edge zoom. Automate fixtures with CLI/Node so a failing hash blocks merge. Document whether you compare pixel buffers or file hashes—PNG re-exports can change filters while pixels stay identical. Keep intermediate .rgbv3d files when filing issues so triage bugs are reproducible across machines.
2026-06-08