Cross-codec robustness experiments for PixelModel-v4 weight images
I ran a controlled experiment to test how different image codecs affect the fp16 weight image used by PixelModel-v4.
The study used the same 100 prompts, seeds, initial latents, 50 sampling steps, CFG 6, and inference settings across all conditions.
Tested formats and settings:
- PNG
- WebP Lossless
- JPEG Q100
- JPEG Q80
- WebP Q80
- AVIF Q70
- JPEG XL distance 1
For each lossy codec, I evaluated three reconstruction methods:
- Raw: directly reinterpret the decoded bytes as fp16 weights
- Finite Repair Zero: replace NaN and ±Inf values with zero
- Protected High Byte: preserve the fp16 high byte losslessly and compress only the low byte
Main results
- PNG and WebP Lossless completed 100/100 generations.
- All five lossy Raw conditions completed 0/100 generations because the reconstructed weight tensors contained non-finite values.
- JPEG was therefore not uniquely fragile in this experiment.
- Finite Repair Zero recovered JPEG Q100 to 100/100, but did not recover JPEG Q80, WebP Q80, AVIF Q70, or JPEG XL d1.
- Protected High Byte completed 100/100 generations for every tested lossy codec.
- The protected conditions recorded zero exponent mismatches.
The protected representations below PNG size achieved approximately:
- JPEG Q80: 36.56% saving
- WebP Q80: 37.67% saving
- AVIF Q70: 39.27% saving
- JPEG XL d1: 37.22% saving
These results are consistent with the hypothesis that preserving the fp16 high byte—containing the sign, exponent, and upper mantissa bits—is more important than preserving the lower byte. However, this experiment does not establish that mechanism as a general causal fact, and Protected High Byte is a hybrid lossless/lossy representation rather than a pure lossy weight artifact.
The full archive, including the detailed README, CSV results, generated samples, codec payloads, visual comparisons, scripts, tests, and verification tools, is available here:
https://huggingface.co/brulee-1/PixelModel-v4-image-codec-study
This study applies specifically to PixelModel-v4 at the pinned revision used by the experiment. The results should not be generalized to PixelModel-v5 or other models without separate evaluation.
Hey! Seems the url is invalid.
Sorry, I forgot to make the repository public.
It’s public now!
@brulee-1 ran your protocol against v5, wanted to actually check rather than assume. reconstructed the model from a protected-high-byte roundtrip and generated with it side by side against baseline, same prompts same seed. bit diagnostics: zero exponent mismatches, zero sign mismatches, fully finite, only mantissa differs same as your v4 numbers. generations are visually identical, couldn't tell them apart.
size is where it breaks though. v4 got you 36-39% savings, v5 comes out 6.8% bigger than baseline PNG. my guess is it's a scale thing, v5's weight image is like 35x the pixels of v4's, and at that size the low byte plane is basically noise, which JPEG Q100 doesn't compress, it can even expand it. haven't dug further than that.
so: correctness holds, the size win doesn't. exactly the "don't assume it generalizes" thing you flagged, confirmed in both directions
appreciate you running this, genuinely useful to have actual numbers instead of guessing. gonna hold off on baking protected-high-byte into v6 as-is since jpeg on the low byte doesn't scale the way it did on v4, but the core idea's solid enough that we'll probably try swapping in a different lossy codec for the low byte and see if that holds up better at bigger sizes. will let you know if anything comes of it
and again thanks for doing this genuinely helped
That’s really interesting — thank you for testing it on v5.
The fact that the protected-high-byte roundtrip still preserves correctness,
while the storage benefit disappears at v5 scale, is exactly the kind of
boundary condition I was hoping the archive would help identify.
Your explanation about the low-byte plane becoming effectively noise at the
larger image size makes sense. I’d be very interested to see whether a
different codec or a weight-aware encoding works better there.
Thanks again for running the comparison and sharing the numbers.
@brulee-1 for sure, please tell us more if you have any interesting findings, would be cool to share and document it, with citation of course