Google Code Exporter
80 lines
6.7 KiB
Markdown
80 lines
6.7 KiB
Markdown
## CRN vs. JPEG+Real-Time DXT1 ##
|
|
|
|
A popular alternative technique involves bolting some sort of real-time DXT compressor onto the back end of a transform coder, like JPEG. JPEG is far from state of the art, but it's very fast and quite popular. The following data shows that CRN is competitive against transform based solutions.
|
|
|
|
In this test, I compressed the test corpus with libjpeg at various bitrates using a binary search to find the JPEG quality factor level closest to each test bitrate. The test bitrates where .75-2.0 bpp at .25 bpp increments.
|
|
|
|
These .JPG files where then unpacked to 24-bit RGB (using the decompressor in [stb\_image.c](http://nothings.org/stb_image.c)), then compressed to DXT1 using [RYG's real-time DXT1 compressor](http://www.farb-rausch.de/~fg/code/). The resulting DXT1 bits where then unpacked using crnlib to 24-bit RGB and compared to the original images to generate this RMSE data:
|
|
|
|
[Charts at various bitrates](http://www.tenacioussoftware.com/crn_stats/dec29/crn_vs_jpg_stats_dec29.htm)
|
|
|
|
[Raw Excel spreadsheet](http://www.tenacioussoftware.com/crn_stats/dec29/crn_vs_jpg_stats_dec29.xlsx)
|
|
|
|
This test shows that, in a RMSE sense, CRN is worse than JPG+RYG\_DXT1 at less than 1.0bpp. Between 1-1.25bpp, CRN is roughly comparable (please excuse the line colors - they are different on each chart):
|
|
|
|
|
|
|
|
Beginning at 1.25bpp CRN is usually better than JPEG followed by real-time DXT1 compression:
|
|
|
|
|
|
|
|
At 1.5bpp or higher CRN was always equal or better:
|
|
|
|
|
|
|
|
These results are similar to [Stromm and Wennersten's published results of testing JPEG followed by ETC1](http://www.jacobstrom.com/publications/StromWennerstenHPG2011.pdf):
|
|
|
|
> "If JPEG is used as the transport format, the textures will need to be compressed on-the-fly to a texture compression format such as ETC1 after download. To find out how much this transcoding will lower the quality, we compressed the JPEG images to ETC1 and measured the average mean square error. The result was an increased error equivalent to a PSNR drop of 2.02 dB than if just ETC1 encoding were used. Thus even if the JPEGs have equal quality to the proposed scheme, after the transcoding there will be a significant quality penalty. The transcoding used slow exhaustive compression—fast transcoding will give an even higher penalty"
|
|
|
|
Also, these observations from the introduction are relevant to this comparison:
|
|
|
|
> "[...] This is often a good solution, especially if low bit rates are of interest, but the resulting texture quality suffers for two reasons: First, the final texture will include image artifacts both from JPEG and from the texture codec. Second, to make recompression from JPEG to the texture codec quick enough, shortcuts may be necessary, especially on mobile devices with limited computational power. This lowers quality, specially when compared to slow, perhaps exhaustive compression."
|
|
|
|
|
|
---
|
|
|
|
|
|
## Raw Data: CRN .75-2.0bpp vs. DXT1 (real-time and offline) ##
|
|
|
|
Here's a [table](http://www.tenacioussoftware.com/crn_stats/dec29/crn_stats_dec_29.htm) containing the RGB [RMSE](http://en.wikipedia.org/wiki/RMSE) of RYG's real-time DXT1 compressor, crnlib's regular DXT1 compressor using uniform or perceptual metrics (which is very similar to ATI\_Compress or squish), and .CRN at .75-2.0bpp at .25bpp increments. This chart also has two columns showing how many bits/pixel are needed by LZMA to compress DXT1 uniform and perceptual .DDS files.
|
|
|
|
Here's a [chart](http://www.tenacioussoftware.com/crn_stats/dec29/rmse_chart.png) of the above spreadsheet, with the images sorted by DXT1 uniform RMSE. and here's the [raw Excel spreadsheet file](http://www.tenacioussoftware.com/crn_stats/dec29/crn_stats_dec_29.xlsx).
|
|
|
|
Note that each .CRN column was generated by specifying the -bitrate option, which really only limits the **maximum** bitrate a file is allowed to use. .CRN is a variable block size format, and the front end limits the maximum endpoint/selector palette sizes to 8192 entries each. So on a few of the simpler images here very high bitrates (like 1.75 or 2.0bpp) may not actually be achievable. (You can see this effect clearly on serrano.)
|
|
|
|
These RMSE values should be comparable to the values in Charles Bloom's very useful [blog post](http://cbloomrants.blogspot.com/2008/11/11-20-08-dxtc-part-3.html) comparing various DXT1 compressors. (My RYG RMSE stats are slightly different from Bloom's, and I don't know exactly why, but I'm guessing our versions of RYG's compressor are slightly different.)
|
|
|
|
|
|
---
|
|
|
|
|
|
## Compressed Images ##
|
|
|
|
Ordered by highest to lowest quality. It's pretty clear that .CRN's subjective quality starts dropping fast around ~1.0 bpp.
|
|
|
|
**crnlib DXT1** (uniform colorspace metrics), RMSE: 8.29, .DDS+LZMA: 2.95 bpp
|
|
|
|
|
|
**RYG DXT1**, RMSE: 8.97
|
|
|
|
|
|
**CRN DXT1 2.0 bpp**, RMSE: 10.36
|
|
|
|
|
|
**CRN DXT1 1.75 bpp**, RMSE: 11.23
|
|
|
|
|
|
**CRN DXT1 1.5 bpp**, RMSE: 12.44
|
|
|
|
|
|
**CRN DXT1 1.25 bpp**, RMSE: 14.2
|
|
|
|
|
|
**CRN DXT1 1.0 bpp**, RMSE: 16.75
|
|
|
|
|
|
**CRN DXT1 .75bpp**, RMSE: 20.69
|
|
|
|
|
|
**CRN DXT1 .65bpp**, RMSE: 22.93
|
|
 |