broken dxt1 compression

[GoogleCodeExporter]

What steps will reproduce the problem?
1. download sources here: http://nvidia-texture-
tools.googlecode.com/files/nvidia-texture-tools-2.0.7-1.tar.gz
2. build release win32 target for nvcompress using visual studio 8
3. execute nvcompress.exe -bc1 mask.tga (targa image attached)

What is the expected output? 
it should look like the .dds produced with an old nvdxt tool (also attached 
mask_ndxt_7.83.dds)

What do you see instead?
the resulting dds is broken (see attached mask.dds)

What version of the product are you using? On what operating system?
nvidia-texture-tools-2.0.7-1

Original issue reported on code.google.com by stoiko.t...@gmail.com on 22 Mar 2010 at 5:45

Attachments:

• mask.tga
• mask.dds
• mask_nvdxt_7.83.dds

[GoogleCodeExporter]

Hmm... that is weird. Thanks for the bug report, I'll try to look at this over 
the
weekend.

Original comment by cast...@gmail.com on 25 Mar 2010 at 7:54

• Changed state: Accepted

[GoogleCodeExporter]

the statement "it should look like the .dds produced with an old nvdxt tool" is 
not 
entirely true. the file "mask_nvdxt_7.83.dds" too has artifacts but they are 
not as bad 
as the ones on "mask.dds"

Original comment by stoiko.t...@gmail.com on 25 Mar 2010 at 8:05

[GoogleCodeExporter]

yeah, in general NVTT should produce better results than the old tools, not sure
what's going on here, but I'll let you know as soon as I find out.

Original comment by cast...@gmail.com on 25 Mar 2010 at 8:37

[GoogleCodeExporter]

This issue does not happen if the color weights are not exactly the same.
Try to call compressionOptions.setColorWeights(1.000001f, 1.000002f, 1.000003f);

I attached a small piece of mask.tga file.

Original comment by marcoalt...@gmail.com on 19 Apr 2010 at 3:03

Attachments:

• 1.tga

[GoogleCodeExporter]

The problem is in the code that computes the principal component. Turns out 
that in
the Red-Green gradients the principal component is (-1, 1, 0). 

To compute it I use the power method which is an iterative algorithm. This 
algorithm
usually converges fairly quickly, however, it needs you to provide an initial
solution. I choose a fairly arbitrary (1, 1, 1) vector, that seemed to work 
well in
most cases. However, in this particular case, when starting with that value, the
algorithm does not converge and gets stuck at (1, 1, 0), which is exactly
perpendicular to the real solution.

I'll see if I can use a better heuristic that is less prone to fail in cases 
like these.

Original comment by cast...@gmail.com on 19 Apr 2010 at 6:00

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision r1057.

Original comment by cast...@gmail.com on 19 Apr 2010 at 6:40

• Changed state: Fixed

[GoogleCodeExporter]

I'm now using the largest vector of the covariance matrix as the starting 
point. That
fixes this particular problem, and in general, I think it should be much more 
robust.

This is fixed in the 2.0 branch and trunk. I'll release the 2.0.8 revision 
fairly soon.

Original comment by cast...@gmail.com on 19 Apr 2010 at 6:44