computeIndices4() comparing unnormalized pallets against normalized colours;

[GoogleCodeExporter]

change this code from:

    for(int i = 0; i < 16; i++)
    {
        Vector3 color = set.color(i).xyz();

        float d0 = colorDistance(palette[0], color);
        float d1 = colorDistance(palette[1], color);
        float d2 = colorDistance(palette[2], color);
        float d3 = colorDistance(palette[3], color);

to: (see color *=255.0f)

    for(int i = 0; i < 16; i++)
    {
        Vector3 color = set.color(i).xyz();
        color *= 255.0f;

        float d0 = colorDistance(palette[0], color);
        float d1 = colorDistance(palette[1], color);
        float d2 = colorDistance(palette[2], color);
        float d3 = colorDistance(palette[3], color);

p.s. i'm simply in the process of integrating nvidia texture tools (svn trunk) 
to our tool base.  And i'm just sending you all those fixes i made to make it 
work at our side.  I'm using no-cuda, yes-freeimages, no-squish, no-atic...(so 
going back to default compressor).  what's your setting alike, ignacio?

p.s.2 I have another fix i've made.. i'll dig it through and let you know

Original issue reported on code.google.com by pope...@gmail.com on 6 Dec 2010 at 8:59

[GoogleCodeExporter]

you will need to do same thing with computeindices3()

Original comment by pope...@gmail.com on 6 Dec 2010 at 9:46

[GoogleCodeExporter]

found another bug in computeindices3().  maxcolour should be set to pallette[0] 
and mincolour should be set to pallette[1]  (it's the other way around at this 
moment)

Original comment by pope...@gmail.com on 6 Dec 2010 at 9:57

[GoogleCodeExporter]

Hmm... I shouldn't have enabled this compressor by default. I was trying to 
implement some quality improvements before the beta and lay the ground for some 
further improvements, but this code is largely untested, and in fact it did not 
improve quality (possibly due to these bugs). In the short term I'm going to 
disable the new compressor while I fix these issues, and reenable it once it's 
properly tested.

Original comment by cast...@gmail.com on 8 Dec 2010 at 8:03

• Changed state: Accepted
• Added labels: Type-Defect

[GoogleCodeExporter]

BTW, now that NVTT supports image loading, I'm considering the use of stb_image 
by default. I've found several problems with freeimage and I don't like the 
idea of distributing a large library along NVTT. People can always enable 
freeimage in their builds if they so desire, or simply use their own image 
loading code and pass the image data directly to NVTT.

Original comment by cast...@gmail.com on 8 Dec 2010 at 8:06

[GoogleCodeExporter]

OK, this the new compressor is disabled after revision 1216.

Original comment by cast...@gmail.com on 8 Dec 2010 at 8:11

• Changed state: Started

[GoogleCodeExporter]

I'm not sure if I will have time to switch from freeimage to stb_image anytime 
soon.  rev 1211 + some of my fixes work fine in our toolchain at this moment. ( 
i rebuilt all textures with no problem ).  Also another tool of ours is still 
using freeimage.

I'll investigate how feasible the switch is when I need to upgrade to a newer 
NVTT in the future.  It'll be most likely when the sharpening filter for 
mipmaps is supported (our tech artist wants it so bad) or after Space Marine is 
shipped :)

Original comment by pope...@gmail.com on 8 Dec 2010 at 8:23

[GoogleCodeExporter]

No, no, I'm just saying that NVTT will use stb_image by default, but the option 
to choose FreeImage at compile time will still be there. So, if you are using 
FreeImage already, I don't see why would you want to change that.

The fixes you proposed look good, but I need to look at them more carefully, 
that index selection code is shared with the fast compressors, and those have 
the colors unnormalized, so I need to figure out how to best handle this in a 
consistent way so that the same code can be shared.

Sorry, for all the trouble, I thought you had grabbed an earlier build already, 
but in any case I should have been more careful with my changes afterwards. 
I'll definitely try to be more careful in the future.

Original comment by cast...@gmail.com on 8 Dec 2010 at 8:47

[GoogleCodeExporter]

naw, don't worry about it. it was all fun. I just needed RGBM conversion right 
now, so I had no choice to grab the trunk.  And I was fully aware of the 
"danger" of getting trunk. :)

About FreeImage.. well I prefer to go with default options all the time if it's 
possible mainly because it's being tested by more people and I want to just 
grab any new build and compile without setting all my custom preprocessors :)

Original comment by pope...@gmail.com on 8 Dec 2010 at 8:53