Extended-container WebP (VP8X, e.g. with ALPH + VP8 chunks) is currently rejected knowingly, and the rejection rationale is sound as far as it goes: stripping only the extended-container header would leave the inner frame header intact and the image trivially restorable — a fragment that is not a key.
But the practical fallout is real: a consumer with a lossy-sourced VP8X asset (~430 KB) had to consider re-encoding to plain lossless VP8L just to get it into cutting range, at a measured shipping cost of roughly +0.85 to +1.3 MB (lossless re-encode of lossy source inflates 3–4x).
Proposal: instead of rejecting VP8X, cut all the format-defining headers together:
- the
VP8X chunk body (canvas size, feature flags)
- the
ALPH chunk header (when present)
- the inner
VP8 /VP8L frame header (dimensions/frame tag)
That preserves key purity — nothing left behind lets a decoder reconstruct the dimensions — and makes the re-encode workaround (and its shipping cost) unnecessary.
Extended-container WebP (
VP8X, e.g. withALPH+VP8chunks) is currently rejected knowingly, and the rejection rationale is sound as far as it goes: stripping only the extended-container header would leave the inner frame header intact and the image trivially restorable — a fragment that is not a key.But the practical fallout is real: a consumer with a lossy-sourced
VP8Xasset (~430 KB) had to consider re-encoding to plain losslessVP8Ljust to get it into cutting range, at a measured shipping cost of roughly +0.85 to +1.3 MB (lossless re-encode of lossy source inflates 3–4x).Proposal: instead of rejecting
VP8X, cut all the format-defining headers together:VP8Xchunk body (canvas size, feature flags)ALPHchunk header (when present)VP8/VP8Lframe header (dimensions/frame tag)That preserves key purity — nothing left behind lets a decoder reconstruct the dimensions — and makes the re-encode workaround (and its shipping cost) unnecessary.