Feature Request: Ability to disable single colour optimization and enable other DXT compression algorithms

[GoogleCodeExporter]

I've come across one of those interesting cases where having a single-color
optimization on DXT compression produces optimal single-color results, but
also introduces artifacts around non-single-color areas due to the
imperfect nature of non-single-color algorithms.

After experimenting with different DXT compression algorithms as provided
in the squish library, it seems that the best way to remove these artifacts
is to disable single-color optimization and just use a straight range-fit
algorithm (the cluster-fit algorithm still produces some artifacts even
with single-color optimization turned off).  While this produces results
that aren't perfect with regards to single-color compression, the
imperfection is uniform across single-color and non-single-color
boundaries, leading to less artifacts.  As such, even though the overall
error is higher, there is still a definite value in exposing this for these
cases, for use at the user's discretion.

Please see the two attached files for a closer look at this.  The
test_nvcompress.dds file is a DXT1 compression with the cluster-fit
algorithm and optimal single-color compression.  The
test_nvcompress_hacked.dds file is a DXT1 compression with the range-fit
algorithm and disabled optimal single-color compression (using a slightly
modified RangeFit.cpp and RangeFit.h found in nvtt/squish, and color
weights of 0.2126f, 0.7152f, and 0.0722f).  Note the artifacts introduced
by the horizontal and vertical lines in the original, as well as the faint
blocks around the "10" in the bottom left hand corner.

It would really be great if the API could make provision for the option to
disable the single-color compression and perhaps allow the user to choose
the compression algorithm.  It could easily be added as a compression
option based on another enumeration (possibly
CompressionOptions::enableSingleColorCompression or
CompressionOptions::setDXTCompressionMode?), but I'm not sure how willing
you are to change the current API.

Please let me know if you would like to see how I modified the NVTT to do
this, but I'm sure that you could do a much cleaner job as you know the
exact code path for a DXT compression.

Original issue reported on code.google.com by jon...@gmail.com on 26 Jun 2008 at 6:35

Attachments:

• test_nvcompress.dds
• test_nvcompress_hacked.dds

[GoogleCodeExporter]

Could you attach the original image as well? I'm not sure the single color 
compressor
is causing the artifacts, but I just noticed that the single color compressor 
does
not take the color weights into account, and should probably be used only when 
the
weights are equal to (1,1,1). If you provide the original, I'll investigate 
this in
more detail.

Original comment by cast...@gmail.com on 28 Jun 2008 at 3:04

[GoogleCodeExporter]

My apologies, it was an oversight on my part not to include the original image 
as
well.  Please find that attached.

Original comment by jon...@gmail.com on 30 Jun 2008 at 4:12

Attachments:

• test.tga

[GoogleCodeExporter]

Original comment by cast...@gmail.com on 11 Oct 2008 at 7:27

• Added labels: Milestone-Release2.1

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Can you test the latest version of NVTT (2.0.6)? It contains an improved single 
color
compressor, that I think should get rid of the artifacts that you were 
experiencing.

Original comment by cast...@gmail.com on 19 Mar 2009 at 9:38

[GoogleCodeExporter]

Original comment by cast...@gmail.com on 19 Oct 2009 at 9:50

• Changed state: Fixed

[GoogleCodeExporter]

Sorry for the tardy reply.  Thanks for your work, as always.

I should have replied earlier to explain that I am no longer working with a 
project 
that requires NVTT, so I haven't really been up to date with exactly what's 
happening here anymore.

Nonetheless, thanks for the fix!

Original comment by jon...@gmail.com on 19 Oct 2009 at 8:23