Red pixel: 255,0,0
Blue pixel: 0,0,255
Seems simple enough, right? Here's what happens with the various encoders (in non-perceptual mode if the encoder supports the flag), using up to date versions from early last week, and non-perceptual RGB avg. metrics for both PSNR and SSIM:
etcpak (PSNR: 15.612, SSIM: 0.265737):
Red pixel: 93,60,93
Blue pixel: 51,18,51
etc2comp ETC1 (PSNR: 17.471, SSIM: 0.372446):
Blue pixel: 60,60,111
Red pixel: 234,47,47
Blue pixel: 47,47,234
basislib_etc1 from yesterday (PSNR: 19.987, SSIM: 0.511227):
Red pixel: 149,47,47
Blue pixel: 47,47,149
etc2comp ETC2 (PSNR: 19.779, SSIM: 0.517508):
Red pixel: 255, 0, 0
Blue pixel: 64,64,98
This is an example of an well-tuned ETC1 encoder (Intel's) holding its own vs. etc2comp in ETC2 mode.
Want a little challenge: Try to figure how how Intel's encoder produced the best output.
John Brooks, the lead on etc2comp, told me that BSI is working with that test image because it's a known low-quality encoding pattern for etc2comp. It wasn't in their test corpus, so the PSNR of 17 & 19 should improve with future etc2comp iterations.
I've improved basislib's handling of this test vector, but the results now need a optimization pass. I've prototyped a version of squish's total ordering method in ETC1, by applying the equations in the remarks in rg_etc1.cpp's code. Amazingly, it competed against rg_etc1's current algorithm for quality on my first try of the new method, but it's slower.