3 ms·
I think Mozilla is right to tread carefully and not commit to yet another format for a minor improvement. In my opinion our web clients are bloated enough as i
by clarry 13y ago
I think Mozilla is right to tread carefully and not commit to yet another format for a minor improvement. In my opinion our web clients are bloated enough as is, and they're only getting bigger. Once you add support for a format and it gains mainstream traction on the web, it'll be really hard to remove, and we'll be stuck with software that has to support so many things for reasons that do not make sense in the near future.
As for the study, I have to admit I did not read it. But the first thing to note is that computed metrics (SSIM, PSNR) are not reliable approximations of perceived quality. Optimizing for either will produce a codec that pleases the computer, not the eye. This is why the tuning of image and video codecs for psychovisual effects is such a laborious, manual process -- you have to have a human viewer to assess the quality.
In the long term I think it would be good if a new still-image format was derived from the intra portion of some reasonably advanced video codec, as they all beat JPEG handily. This is essentially what WebP is, but if I recall correctly, Google didn't really give VP8 the love it needed when they acquired On2. Instead they rushed with a "release early, release often" mentality, presumably hoping the community would jump the boat first and do the grunt work for them later (this was during html5 video wars when some thought Theora sucks and others thought h.264 is too encumbered -- VP8 was Google's resolution). The details are shady but the curious should search for the debate around early VP8 (I think the x264 folk did some extensive notes). Needless to say I think, VP8 (and WebP) wasn't and isn't the game changer Google would've hoped.
To avoid patents, a reasonable choice would IMHO be to look at Xiph.Org's upcoming video codec Daala. Curiously Mozilla has the right man in house since Monty moved from Red Hat to Mozilla like, almost like yesterday... Daala however isn't quite ready yet as the Xiph guys are busy researching out new ideas and unicorns. But the results so far are very interesting to say the least; anyone interested should check out Monty's demo pages.[1]
As others have said, JPEG is "good enough" for most of us, and even JPEG is used rather inefficiently, often with too high quality. So there's no compelling reason to push for a new format here-and-now. Give it some time and commit once there's something significant I say. In the future we'll thank ourselves for not having deployed all that junk over minor increments.
[1] http://people.xiph.org/~xiphmont/demo/ http://people.xiph.org/~xiphmont/demo/
- pornel 13y agoMozilla hasn't used PSNR. They've used PSNR-HVS-M, which is more sophisticated. In test of objective metrics SSIM was one of the best (0.8 spearman correlation with human scores) http://www.ponomarenko.info/tid2008.htm http://www.ponomarenko.info/tid2008.htm IHMO the study has been done very well. They've even eliminated potential differences coming from colorspace conversion and chroma subsampling. If anything, this study favors WebP that can't do full-resolution color.
- clarry 13y agoRight, I probably came across not quite as intended; sorry about that. I didn't mean to say the study is hosed (which I can't say because I didn't read it!), the remark about objective metrics was a more general one. Yes, SSIM is one of the better metrics available, and obviously it's useful for certain things. However it still doesn't accurately represent preceived quality; time and time again certain psy optimizations for instance are shown to reduce SSIM while perceived quality goes up. Conversely, a codec can optimize for SSIM alone and score well on a test that ranks by SSIM; but the perceived quality could be better. For this reason e.g. x264 has an option to disable psy optimizations that hurt the objective metrics. There are other things that can hurt metrics a lot while doing nothing perceptible, though these are rather like bugs or errors in testing methodology, and as such would likely be noticed in a well conducted study. See also: https://wiki.xiph.org/Notes_on_testing_theora#General_points_on_.22objective.22_measures_like_PSNR_and_SSIM https://wiki.xiph.org/Notes_on_testing_theora#General_points...
- brigade 13y agoFrom what I can tell, for Y-SSIM and IW-SSIM they appear to be encoding color images but only measuring the luma component, which is invalid and renders the results meaningless. Unless they're actually encoding greyscale images for those sections without mentioning it? BTW HEVC-MSP is limited to 4:2:0 only as well.
- joshmoz 13y agoStudy author here. For Y-SSIM and IW-SSIM we convert the images to grayscale (MATLAB 'rgb2gray') before running the scoring algorithms. We aren't running the algorithms on luma planes. See published code and methodology.