How does the speed compare to other compression algorithms?
I'm sure this could be increased by a huge amount if I had a not-terrible CPU or if I did some major refactors to use the GPU.
I don't think this approach can compete with JPEG and newer transform based variants for natural photos (event at edge cases), but seems like it would be nice for lossy compression of logos/general internet pics.
The point is, is that technique in between JPEG and PNG in terms of quality/size or is it worse than JPEG altogether ?
However, it handles gradients amazingly. A full colour gradient such as [0] can be made a tenth of the size since only ~500 samples are really needed.
> No text at all
Or indeed anything which poorly maps to gradients. For this I'm thinking about instead of storing pixel values per sample vertex, store only dct coefficient(s) per each tri - result of which gets texture-like-mapped to the tri surface. Think JPEG instead of 8x8 quads using variably sized tris.
JPEG artifacts would then be much more fine grained around edges.
EDIT: It would not need to be as complex as full DCT because a lot of information is carried through tri shape/positioning on edges. The idea is to have "library of various gradient shapes" to pick from, not full 8x8 DCT matrix capable of reconstituting 8x8 bitmap approximations.
Once again, thanks for inspiring implementation.