Show HN: Trigrad, a novel image compression with interesting results
1–10 of 69 posts
Re: Show HN: Trigrad, a novel image compression with interesting results
#2Re: Show HN: Trigrad, a novel image compression with interesting results
#3How 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.
Re: Show HN: Trigrad, a novel image compression with interesting results
#4Re: Show HN: Trigrad, a novel image compression with interesting results
#5How does the speed compare to other compression algorithms?
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.
Re: Show HN: Trigrad, a novel image compression with interesting results
#6Earlier quoted context omitted.
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.
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?
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.
Re: Show HN: Trigrad, a novel image compression with interesting results
#7How does the speed compare to other compression algorithms?
Re: Show HN: Trigrad, a novel image compression with interesting results
#8Earlier quoted context omitted.
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?
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.
The point is, is that technique in between JPEG and PNG in terms of quality/size or is it worse than JPEG altogether ?
Re: Show HN: Trigrad, a novel image compression with interesting results
#9Earlier quoted context omitted.
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.
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?
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.
Re: Show HN: Trigrad, a novel image compression with interesting results
#10I'd be curious to know how this stacks up in terms of speed and quality.
EDIT: Oh yes, and there's also "Image Compression Using Data-Dependent Triangulations" and "Survey of Techniques for Data-dependent Triangulations Approximating Color Images", both by Lehner et al., 2007. I don't mean to discourage you here, just pointing out the bar to be beaten. It's a cool idea.