Live data from Hacker News

Show HN: Trigrad, a novel image compression with interesting results

ruarai.github.io

41–50 of 69 posts

Re: Show HN: Trigrad, a novel image compression with interesting results

#41
Hmmm... I wonder if there's potential to use this concept for video. Not this implementation, naturally, but the concept.

I'm a little too sleep deprived to think through this entirely, but just off the top of my head, it seems like over the course of a few frames that an edge in motion would wind up as a series of triangles where one of the points remains static while the other two shift away from it -- in other words, the Trigrad approach would yield motion blur as an artifact. And then when the next key frame comes along, the remaining point gets reselected, probably further along the motion path... So much like a normal differential approach you wouldn't need to store all of the point locations each frame, just the ones that change and which triangle they belong to.

It might be hard to make it stream-friendly though, since obviously the compression efficiency depends heavily on the storage structure (see pjtr's comments)...

Re: Show HN: Trigrad, a novel image compression with interesting results

#42
This makes me feel obligated to share my ongoing master thesis project. Among other things, my approach is the reverse to this, namely decimating a full detail mesh using edge/ridge detection.

https://femtondev.wordpress.com/2014/12/18/not-delaunay/

https://femtondev.wordpress.com/2014/12/12/principal-compone...

Re: Show HN: Trigrad, a novel image compression with interesting results

#43
Reading how this works, I'm a bit disappointed in how the low sample images performs, particularly for the stems. It feels like one should be able to tweak this to get much better results in this situation. I'm disappointed in the amount of yellow over the stem.

Here's my first thought on what could improve that: samples are taken at edges, which is exactly where colors vary quickly. So perhaps samples should be taken in pairs, one on either side of the edge.

Fun project!

Re: Show HN: Trigrad, a novel image compression with interesting results

#44

This is the difference between someone who actually does something and academic work that claims to achieve something. This is half-done, but it WORKS and you can use it and understand it right now. I had the opportunity to try and implement a "novel" algorithm for image downscaling. I contacted the authors - one replied that he can't reveal the source code, and the other didn't reply. So I went ahead and invested ab…

In my experience[1] code is available maybe half of the time, if you really search for it: checking the academic and personal pages of every author, and scouring the code of every framework mentioned. You're lucky when the code is in C or C++ using a framework nobody uses (e.g. MegaWave), but half of the time the code is in MATLAB. All uncommented, using single character variables and under some restrictive or just weird license.

And then it only works on grayscale images. Maybe because it's easier to get funding for medical images. Just applying the algorithm to each color channel separately leads to color fringing when they get out of sync.

Finally, usability, distribution, and performance are afterthoughts. I don't disagree but it makes a huge difference.

[1] https://github.com/victorvde/jpeg2png

Re: Show HN: Trigrad, a novel image compression with interesting results

#45
post #35

This is the difference between someone who actually does something and academic work that claims to achieve something. This is half-done, but it WORKS and you can use it and understand it right now. I had the opportunity to try and implement a "novel" algorithm for image downscaling. I contacted the authors - one replied that he can't reveal the source code, and the other didn't reply. So I went ahead and invested ab…

I mean the author no harm, nor want to talk bad about his work. His work is very cool and I like the amount of information that he gives. Yet, this is far from comparable to academic work. I am inclined to say that you mixed up the sides in your statement, IMHO. Academic work would have explained the benefit of the algorithm. It would have presented it with a side by side comparison with common algorithms and explain…

[deleted]

Re: Show HN: Trigrad, a novel image compression with interesting results

#46
post #25
post #21

Earlier quoted context omitted.

I'm missing where they are sorted by x-y values. I did a quick and dirty experiment: http://pastebin.com/NjZNRjw1 Seems about 30% smaller than before on http://i.imgur.com/5zwCEF5.png

Wow, that works pretty well. I was mistaken in thinking that either the Dictionary class or the process of sampling would sort them. Mind if I merge that? Or you could submit a pull request. Either would be great! Also, do you know of any resources for learning about how to optimise for gzip compression? Google is just telling me about compression for websites.

Compression gurus hang out at http://encode.ru

You'll likely find a compressor much more suited to your particular data than gzip.

Re: Show HN: Trigrad, a novel image compression with interesting results

#47
post #43

Reading how this works, I'm a bit disappointed in how the low sample images performs, particularly for the stems. It feels like one should be able to tweak this to get much better results in this situation. I'm disappointed in the amount of yellow over the stem. Here's my first thought on what could improve that: samples are taken at edges, which is exactly where colors vary quickly. So perhaps samples should be take…

The "easy" way to do this is to run the edge detection twice. In other words, run edge detection, then run edge detection on the result of the edge detection.

Re: Show HN: Trigrad, a novel image compression with interesting results

#48
I have an improvement to this:

Run the edge detection twice. That way you get better gradients along sharp edges.

Single run: http://i.imgur.com/kusJDRo.png

Double run: http://i.imgur.com/rHYSzpq.png

To me, at least, the double looks better. Especially in the stems.

Just add the following to FrequencyTable.cs, after line 18 (var edges = ...)

    detector = new SobelEdgeDetector();
    edges = detector.Apply(edges);

Re: Show HN: Trigrad, a novel image compression with interesting results

#49

This is the difference between someone who actually does something and academic work that claims to achieve something. This is half-done, but it WORKS and you can use it and understand it right now. I had the opportunity to try and implement a "novel" algorithm for image downscaling. I contacted the authors - one replied that he can't reveal the source code, and the other didn't reply. So I went ahead and invested ab…

I agree that it's nice to have this kind of write up and code, but "works" is a low bar to pass, especially in image compression. If this were written up as an academic paper, a few questions would have to be answered:

* what is the related work?

* can you put any bound on the error of the reconstruction?

* how does performance vary across resolution, noise, and content?

* how does that compare to the other state-of-the-art methods?

Without that, how do we know whether this is worth using?

Re: Show HN: Trigrad, a novel image compression with interesting results

#50
post #35

This is the difference between someone who actually does something and academic work that claims to achieve something. This is half-done, but it WORKS and you can use it and understand it right now. I had the opportunity to try and implement a "novel" algorithm for image downscaling. I contacted the authors - one replied that he can't reveal the source code, and the other didn't reply. So I went ahead and invested ab…

I mean the author no harm, nor want to talk bad about his work. His work is very cool and I like the amount of information that he gives. Yet, this is far from comparable to academic work. I am inclined to say that you mixed up the sides in your statement, IMHO. Academic work would have explained the benefit of the algorithm. It would have presented it with a side by side comparison with common algorithms and explain…

This is the traditional model of academic publishing that was driven by the limited communication and collaboration ability of the time. A study like the one you describe would be done by multiple co-authors (I don't think I've written an image processing paper that doesn't have at least three people as authors, all of whom actually contributed to the work one way or another.)

Furthermore, the traditional paper would have to make a lot of guesses about the kinds of images people were likely interested in and the range of characteristics that mattered. What kind of noise spectrum due your images have, how does increasing contrast affect things, what about the spacial frequency distribution in the images themselves, and so on... Different fields have radically different "typical" images and the attempts at covering a reasonable range of the in traditional papers were not necessarily very limited.

Instead, I see this model of publication as exploiting the possibilities of the 'Net to allow more effective communication and collaboration. And it is publication: it is making public, which is what makes the difference between science and alchemy... if there had been a "Proceedings of the Alchemical Society" we'd have had chemistry a thousand years ago.

What this model of publication does not (yet) have is a reputation mechanism, but it isn't clear it needs one, because you can see the results (and the code) for yourself. As such, I think the author has not only done something interesting in the image compression space, they are pointing the way on the future of scientific publication.

Measuring this model as if it could be described as a certain amount of progress along a line toward the old endpoint is mistaken. This is a paradigm shift, and the models are incommensurable.

Post reply on HN