KarpelesLab / gowebp / 24428650643

93%

Build Type

push

github

Committed by MagicalTux

Commit Message

fix: BT.601 limited-range YCbCr color type (BT601YCbCrColor)

WebP's VP8 stores pixels in limited-range BT.601 per RFC 6386 (luma
16-235, chroma 16-240). Go's stdlib image/color.YCbCrToRGB applies
the JFIF (full-range) inverse regardless, which shifts RGB output by
2-5 units per channel on VP8 content. Previously we just documented
this in the README and asked users to be careful.

Now handled automatically: Decode wraps VP8 results in a new
*BT601YCbCr (or *BT601NYCbCrA for ALPH-bearing sources) whose At()
method uses the correct limited-range inverse:

  R = clip((298·(Y-16) + 409·(Cr-128) + 128) >> 8)
  G = clip((298·(Y-16) - 100·(Cb-128) - 208·(Cr-128) + 128) >> 8)
  B = clip((298·(Y-16) + 516·(Cb-128) + 128) >> 8)

New exports:
  - BT601YCbCrColor       — single-pixel spec-correct YCbCr color
  - BT601NYCbCrAColor     — same with alpha
  - BT601YCbCr / BT601NYCbCrA — image wrappers around the stdlib
    types; embedded field is accessible for zero-copy plane access
  - BT601YCbCrColorModel / BT601NYCbCrAColorModel

Test evidence: same VP8 pixel YUV(137,157,103) decoded to
  - BT601YCbCrColor.RGBA() → (101, 150, 199)  — correct (source was
    RGB 100,150,200)
  - stdlib color.YCbCrToRGB → (102, 145, 188) — 5-12 units off

VP8L (lossless) passes through unchanged since it decodes directly
to NRGBA without going through YCbCr.

This is a behavioral change: callers who type-asserted
\`Decode(r).(*image.YCbCr)\` now see \`*gowebp.BT601YCbCr\` instead.
They can unwrap via the embedded .YCbCr field.

Coverage Stats

37 of 109 new or added lines in 2 files covered. (33.94%)

13 existing lines in 1 file now uncovered.

2973 of 3194 relevant lines covered (93.08%)

108574.05 hits per line