4 ms·

Currently compressing the example image (the one of the flowers) with 100,000 samples takes 1.5 seconds + 1.5 seconds for AForge's edge detection. I'm sure thi

by ruarai 11y ago

Currently compressing the example image (the one of the flowers) with 100,000 samples takes 1.5 seconds + 1.5 seconds for AForge's edge detection. 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.

ekianjo 11y ago
How does it compare in quality/size vs PNG ? How about using examples where JPG are traditionally bad at, such as pictures with dark gradients leading to blocky artifacts? Would that process be more efficient there?
- darkmighty 11y ago
  PNG is lossless, so I don't get the quality comparison. 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.
  - ekianjo 11y ago
    > PNG is lossless, so I don't get the quality comparison. The point is, is that technique in between JPEG and PNG in terms of quality/size or is it worse than JPEG altogether ?
- ruarai 11y ago
  It's not very comparable to PNG, since they're designed for different types of imagery. I know currently Trigrad cannot handle text at all. In regards to your other comment, it's currently definitely worse than JPEG for vector imagery. 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. [0] http://i.imgur.com/QzW0z2O.png http://i.imgur.com/QzW0z2O.png
  - ezdiy 11y ago
    Love how the algorithm is simple compared to iDCT based ones, very good job! > 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.

by ruarai 11y ago

ekianjo 11y ago

How does it compare in quality/size vs PNG ? How about using examples where JPG are traditionally bad at, such as pictures with dark gradients leading to blocky artifacts? Would that process be more efficient there?

darkmighty 11y ago
PNG is lossless, so I don't get the quality comparison. 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.
- ekianjo 11y ago
  > PNG is lossless, so I don't get the quality comparison. The point is, is that technique in between JPEG and PNG in terms of quality/size or is it worse than JPEG altogether ?
ruarai 11y ago
It's not very comparable to PNG, since they're designed for different types of imagery. I know currently Trigrad cannot handle text at all. In regards to your other comment, it's currently definitely worse than JPEG for vector imagery. 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. [0] http://i.imgur.com/QzW0z2O.png http://i.imgur.com/QzW0z2O.png
- ezdiy 11y ago
  Love how the algorithm is simple compared to iDCT based ones, very good job! > 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.