[Webkit-unassigned] [Bug 51719] [chromium] PNG compression settings optimized for speed

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=51719





--- Comment #6 from Cosmin Truta <ctruta at chromium.org>  2011-01-04 13:02:31 PST ---
(In reply to comment #4)
> I'm not really an expert here.  If you can Noel can come to agreement, that's fine with me.

I don't think there actually is a disagreement between me and Noel. It _looks_ like a disagreement between my analysis here, and my other analysis from an article that I wrote 10+ years ago that Noel quoted -- in fact, it's just me clarifying what I wrote in that article.

As far as I understood from Noel's notes in bug 51455, he quoted my Z_RLE compression strategy proposal that I pitched to the zlib developers. (That pitch worked: Z_RLE is now in zlib.)
http://optipng.sourceforge.net/pngtech/z_rle.html

That article was about proposing a compression strategy (namely Z_RLE) that is as fast as, but gives better compression than Z_HUFFMAN_ONLY. Otherwise, Z_RLE inherits both the strenghts and weaknesses of Z_HUFFMAN_ONLY, although I didn't say that explicitly. That probably lead to this confusion.

The image test set used in that proposal was restricted to photographs; this is where these two strategies are good at. On the other hand, in my experiements here, I'm outlining the weakness of both of these strategies. I should probably update my PNGTech site with a new article, to alleviate the confusion that I created here, and, who knows, maybe elsewhere...

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.