On Thursday, October 17, 2013 7:48:16 AM UTC-7, Josh Aas wrote: > This is the discussion thread for the Mozilla Research blog post entitled > "Studying Lossy Image Compression Efficiency", and the related study.
Few queries regarding the study's methodology: 1.) The compression_test.py code converts the input PNG image to YUV data via following command (for Lenna image for instance): convert png:Lenna.png -sampling-factor 4:2:0 -depth 8 Lenna.png.yuv Not sure, what's the default colorspace used for imagemagick's convert command. Seems, as per imagemagick's documentation, this will produce YUV data (Luma range [0..255] and not digtal YCbCr (Luma range [16..235]), unless '-colorspace Rec601Luma' is specified). If the YUV intermediate data produced above is not YCbCr, not sure if that YUV data is a valid input for WebP like encoder. Can we verify that the correct YCbCr data is generated from the convert command (above). 2.) How the quality scores (Y-SSIM etc) will look like, if we skip generating this intermediate (YUV) data and encode (at some lossy quality) the source (RGB colorspace) PNG image directly to Jpeg & other codecs (WebP etc) via imagemagick's convert command and convert these images (Jpeg, WebP etc) back to PNG format (without intermediate YUV step) and evaluate the quality scores (Y-SSIM, RGB-SSIM etc) on the source and re-converted PNG files. 3.) JPEG compression being equal or better (on Y-SSIM quality score) than HEVC at higher qualities for Technique image set looks little suspicious to me. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
