On Feb 23, 2014, at 5:17 PM, evacc...@gmail.com wrote: > On Monday, October 21, 2013 8:54:24 AM UTC-6, tric...@accusoft.com wrote: >>> - I suppose that the final lossless step used for JPEGs was the usual >>> Huffman encoding and not arithmetic coding, have you considered testing the >>> later one independently? >> >> >> >> Uninteresting since nobody uses it - except a couple of compression gurus, >> the AC coding option is pretty much unused in the field. > > Nobody uses it because there's no browser support, but that doesn't change > the fact that it's overwhelmingly better. And if you're going to compare > JPEG to a bunch of codecs with horrible support in the real world, it seems > pretty unfair to hold JPEG only to features that are broadly supported. > Also, last I looked, the FF team refused to add support for JPEGs with > arithmetic encoding, even though the patent issues have long since expired > and it's already supported by libjpeg. > > IMO, it's silly not to let JPEG use optimal settings for a test like this, > because promulgating an entirely new standard (as opposed to improving an > existing one) is much more difficult.
Perhaps it’s easier. However, the point though was to see if new image formats were sufficiently better than what we have now to be worth adding support for, not to compare image formats to see which one is best. > I would also like to see the raw libjpeg settings used; were you using float? > Were the files optimized? These are easy questions for you to answer by reading the source yourself. -Jeff _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
