Image quality regression

[GoogleCodeExporter]

I noticed that the squish branch in the NVIDIA Texture Tools produces slightly 
higher 
quality than the latest version of squish.

Here are the RMSE that I get on a standard set of images:

             squish      NVTT        DIFF
kodim01.png 8.290677    8.275274    0.015403
kodim02.png 6.264800    6.204140    0.060660
kodim03.png 4.893167    4.872263    0.020904
kodim04.png 5.785400    5.749871    0.035529
kodim05.png 9.666156    9.651270    0.014886
kodim06.png 7.165666    7.153911    0.011755
kodim07.png 5.862642    5.841345    0.021297
kodim08.png 10.275237   10.239549   0.035688
kodim09.png 5.342344    5.329803    0.012541
kodim10.png 5.312246    5.290972    0.021274
kodim11.png 6.785249    6.772330    0.012919
kodim12.png 4.850367    4.833756    0.016611
kodim13.png 10.896658   10.87993    0.016728
kodim14.png 8.333256    8.314128    0.019128
kodim15.png 5.929647    5.897056    0.032591
kodim16.png 5.130026    5.118624    0.011402
kodim17.png 5.588973    5.579279    0.009694
kodim18.png 8.036373    8.015795    0.020578
kodim19.png 6.621748    6.613124    0.008624
kodim20.png 5.511690    5.486531    0.025159
kodim21.png 7.169297    7.158374    0.010923
kodim22.png 6.487758    6.474782    0.012976
kodim23.png 4.980631    4.965201    0.015430
kodim24.png 8.455920    8.414561    0.041359
clegg.png   15.175355   14.996866   0.178489
frymire.png 12.486885   12.053708   0.433177
lena.png    7.085361    7.064801    0.020560
monarch.png 6.609877    6.600169    0.009708
peppers.png 6.458308    6.433527    0.024781
sail.png    8.359949    8.341820    0.018129
serrano.png 6.549851    6.365134    0.184717
tulips.png  7.639101    7.622415    0.016686
Bradley1.png    13.535675   13.528776   0.006899
Gradient.png    0.752600    0.752600    0
MoreRocks.png   8.888842    8.888280    0.000562
Wall.png    12.408543   12.408283   0.000260
Rainbow.png 2.197008    2.185532    0.011476
Text.png    6.638536    6.483967    0.154569

I'm a bit puzzled by that. I've confirmed it's not caused by the recent 
optimizations 
in the computation of the alpha beta terms. NVTT uses the power method to 
compute the 
best fit axis, and that seems to produce slightly better results, but doesn't 
account 
for all the differences.

I also noticed that increasing the number of iterations produces only a minimal 
effect 
on the resulting quality. It makes me wonder if it's really worth the added 
complexity.

If old releases were available for download it might make it easier to find out 
when 
the regression was introduced.

Original issue reported on code.google.com by cast...@gmail.com on 25 Nov 2008 at 7:12

[GoogleCodeExporter]

I realise it's been a few months, apologies for that.  I'm finally trying to 
look
into this issue.

For the current trunk revision, here is the RMS I get for cluster fit 
(non-iterative):

kodim01.png 8.33519
kodim02.png 6.2648
kodim03.png 4.89315
kodim04.png 5.7854
kodim05.png 9.71045
kodim06.png 7.19615
kodim07.png 5.86264
kodim08.png 10.3137
kodim09.png 5.34234
kodim10.png 5.31225
kodim11.png 6.79347
kodim12.png 4.85037
kodim13.png 10.9275
kodim14.png 8.37094
kodim15.png 5.92965
kodim16.png 5.13003
kodim17.png 5.58897
kodim18.png 8.0668
kodim19.png 6.6252
kodim20.png 5.51169
kodim21.png 7.18417
kodim22.png 6.48776
kodim23.png 4.98063
kodim24.png 8.51053

I know it was a long time ago, but do you remember how you generated your 
numbers?  I
have generated them using uniform weights (1.0f, 1.0f, 1.0f) in both the 
cluster fit
and RMS error calculation.

Original comment by sidm...@gmail.com on 2 Apr 2009 at 9:47

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I think I used this code:

http://code.google.com/p/nvidia-texture-tools/source/browse/trunk/src/nvtt/Compr
essDXT.cpp#630

and then used a modified version of nvtestsuite to compute the RMS of the test 
images:

http://code.google.com/p/nvidia-texture-tools/source/browse/trunk/src/nvtt/tests
/testsuite.cpp

In particular, I add this line:

compressionOptions.setExternalCompressor("squish");

I think I used the msvc8 compiler. I guess that compiler version and settings 
could
explain the differences, but in my test I believe I used the same compiler for 
both.
It was long time ago, I should probably repeat the tests to make sure I didn't 
miss
anything, and that the same result can still be reproduced.

Original comment by cast...@gmail.com on 3 Apr 2009 at 12:55

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Thanks for the update, I did this test using gcc 4.3 on x86_64.  I'll do the 
same
test on msvc9 (express) and see what the results are.

The test code I'm using is here:
http://code.google.com/p/libsquish/source/browse/trunk/extra/squishpng.cpp#420

There has to be a reason, so worst case I'll just drop your version of squish 
over
the top of this and see what happens. :)

Nice blog post on hardware implementation and tolerances for intermediate 
points btw,
very interesting to see that this can cause issues in real textures (and can be 
avoided).

Original comment by sidm...@gmail.com on 3 Apr 2009 at 7:53

• Changed state: Started
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Quick update: the RMS error values from your test suite I just built and ran 
are not
as good as the values back in Nov 08.  However, the values are still an 
improvement
on the current squish.  One difference between the two cluster fits is that I
intentionally skip cluster fit configurations where all samples are assigned to 
an
endpoint, since the least squares solution is under-specified for this case, 
but this
does not seem to bring things in line.

The plot thickens... :)

Original comment by sidm...@gmail.com on 3 Apr 2009 at 10:50

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

:)

The values could be slightly worse now, because the updated single color 
compressor
is more conservative. I don't remember any other changes that could impact 
quality...
I recently wrote a testsuite to checks for regressions, but I'm not running it
periodically...

Original comment by cast...@gmail.com on 3 Apr 2009 at 11:06

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

There are lots of differences in the code. 
* NVtt doesn't use a minimal colour-set. It always uses 16 colours, even if 
they occur multiple times. 
* It doesn't square the weights in the set even if you make it use a minimal 
set.
* It uses the "metric" in creating the covariance matrix
* It uses (AFAIS mathematically correcty) a squared "metric" in the cluster-fit.
Maybe more, that's what I saw just skimming.

Original comment by spamt...@adsignum.com on 31 Oct 2012 at 7:30

• Added labels: ****
• Removed labels: ****