hwixlab / nvidia-texture-tools Goto Github PK

DXT1a is now supported, but the CUDA compressor is missing.

This lib compress only DXT1 format and not DXT5.
Do you plan to support this format soon (With cuda)?

I'd like to see continued support for the Photoshop DDS load/save plugin.
I'm currently using version 8.23.1101.1715 in WinXP Pro sp2 with Photoshop
CS3. 

Many game development artists are using this tool. There is really no other
replacement for what it does.

Current problems:
1. Cubemap mips are loading incorrectly. See this post:
http://developer.nvidia.com/forums/index.php?showtopic=1092

2. Volume texture is not saving properly. See this post:
http://developer.nvidia.com/forums/index.php?showtopic=734

Preferred handling of cubemaps would be a pow-2 square 2D image, with six
Layers, one for each of the six sides. The plugin could assume the Layers
to be arranged in order from top to bottom, +X to -Z. If "Use existing
mips" is turned on, the plugin could assume each layer to contain its own
mips, arranged left-to-right from largest mip to smallest mip (smallest
being 1 pixel). 

Volume maps could be a similar setup using Layers. Top layer = top slice. #
of layers = # of slices. This could support non-square dimensions as well,
though I'm not sure how the plugin could deduce the mip layout for "Use
existing mips" if the image is non-square.

Thanks for considering this!
Eric

Add support for normal map encoding using DXT1. The quality is poor, but on
some hardware DXT1 has great advantages over DXT5.

could we have an option to turn off the %<percentage complete> output in
myOutputHandler::writeData()?

What steps will reproduce the problem?
Load any non-compressed (DDPF_RGB) DDS image that has a zero alpha mask
(for example with the nvdecompress utility)

What is the expected output? What do you see instead?
Load hangs infinitely.

What version of the product are you using? On what operating system?
Latest svn (revision 94).

Please provide any additional information below.
A patch which fixes the problem is attached. Note that I was not entirely
sure how to fix the convert function, but it seems to work.

I've integrated the texture tool into our tool pipeline, which uses msbuild
to execute tasks based on dependency checking.  I'd like it if there was an
option so that the error messages followed the msbuild error format:

http://blogs.msdn.com/msbuild/archive/2006/11/03/msbuild-visual-studio-aware-err
or-messages-and-message-formats.aspx

Currently the NVTT library has to be compiled for a specific instruction
set. The SSE2 code path is 40% faster than the SSE code path, and no SSE is
much slower, 3-4 times slower. It would be nice to automatically select the
best code path dynamically according to the available CPU capabilities.

including 3D texture compression formats (DXT and VTC).

I am new to this field of Image Processing and GPU so please bare with me.

Where will you use hardware accelerated DXT compressor? Is it to store
compressed texturs in the buffer? What if I want to read the bitmaps from
the GPU (glReadPixels()) and process it may be by sending them to the
different machine. Could I use this compressor to compress these bitmaps.
Also I won’t need to move them from GPU to CPU to compress using software
so it will be faster.

Also do you more information on nvimagediff tool?

Thanks. 

Scaling support similar to the older texture tool would be nice to have. 
This is useful for multi-platform development where you want to scale
textures to different sizes depending on how much memory you may have.

Support for the A8L8 format.
Regarding how to treat the RGBA input data, it could be either by using a
set convention (like R->A, G->L) or allowing it to be set as an option.

What steps will reproduce the problem?
1. svn revision 30 does not compile out of the box on OS X.

What is the expected output? What do you see instead?
Error in Debug.cpp, line 170.

What version of the product are you using? On what operating system?
svn revision 30, OS X 10.4.9 on Intel.

Please provide any additional information below.
A couple of places in code seem to be using NV_OS_OSX macro, but it looks like 
that should be 
NV_OS_DARWIN one.

Attached a file that makes codebase compile.

There's no dds to tga converter in the toolset (as the one there used to be
in nvdxt). I patched one up.

Add support for YCoCg-DXT5 texture compression as described in:

http://developer.nvidia.com/object/real-time-ycocg-dxt-compression.html

It's nice that the texture tools have been released under the MIT license,
but it looks like US citizens can't legally use it. The patent on block
compression(S3TC) won't expire until 2017 and the MIT license doesn't grant
me(or other users) any use of the S3TC patent. Simon Brown isn't located in
the USA, so the patent doesn't apply to him. I've wanted to use Simon
Brown's library many times, but alas, it would be illegal to compile it in
the USA without separately licensing the S3TC patent...

US S3TC Patent
http://patft.uspto.gov/netacgi/nph-Parser?u=%2Fnetahtml%2Fsrchnum.htm&Sect1=PTO1
&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=5956431.PN.&OS=PN/5956431&RS=PN/5956431

I know NVidia has a license for the S3TC patent, but unless NVidia is
sub-licensing the S3TC patent along with the code, it appears this can't be
used by US citizens.

On G80 hardware mipmap generation takes longer than compression. An accelerated 
implementation of the mipmap convolution filter would result in a great speedup.

The image loading libraries used by NVTT use the prebuilt libraries
provided by the gnuwin32 project. These libraries are only available for
win32, so on win64 the loaders for jpeg and png are not available. 

A simple solution would be to use stb_image as a fallback for systems where
the standard libraries are not available:

ttps://mollyrocket.com/forums/viewtopic.php?t=315

The alpha channel of the image can be interpreted in different ways. Some
images use it as an independent channel, others use it for transparency,
while others assume that colors are premultiplied by the alpha channel.

The compressor should behave in different ways according to that. Currently
fast compressors behave as if the alpha was independent, but the others
behave as if it was used for transparency.

There's an API available to specify the alpha mode:

/// Alpha mode.
enum AlphaMode
{
    AlphaMode_None,
    AlphaMode_Transparency,
    AlphaMode_Premultiplied,
};

void InputOptions::setAlphaMode(AlphaMode alphaMode);

but it's not being used yet.

Any chance you could put together an updated package of win32 binaries +
source code?

I'm trying to just grab the source code via svn, but am running into
issues... hrrm.

-sam

Mip Map Filtering options from the old texture tool would be nice to have
back in the new tool.

NVTT crashes when runs out of memory when generating mipmaps of a 8192 x
8192 texture on 32 bit OS's. It would be nice to detect the problem and
fail reporting the issue with a descriptive error code.

A better alternative would be to actually support unlimited image sizes by
processing the image in tiles.

What steps will reproduce the problem?
1. Building using "cmake . && make" on Fedora 7 x86_64

What is the expected output? What do you see instead?

It should build normally, but instead:

[per@localhost nvidia-texture-tools]$ make
Scanning dependencies of target nvcore
[  2%] Building CXX object src/nvcore/CMakeFiles/nvcore.dir/Memory.o
/home/per/devinstall/nvidia-texture-tools/src/nvcore/Memory.cpp:1: error:
CPU you selected does not support x86-64 instruction set
/home/per/devinstall/nvidia-texture-tools/src/nvcore/Memory.cpp:1: error:
CPU you selected does not support x86-64 instruction set
make[2]: *** [src/nvcore/CMakeFiles/nvcore.dir/Memory.o] Error 1
make[1]: *** [src/nvcore/CMakeFiles/nvcore.dir/all] Error 2
make: *** [all] Error 2

What version of the product are you using? On what operating system?

Both version 0.9.4 and svn trunk revision 76 fail as above.

Please provide any additional information below.

Patch that should fix the problem is attached. It detects g++ and sets the
use of SSE3 in a way that should not break with x86_64 processors.

Cubemap support from the older texture tool:

  -cubeMap : create cube map .
           Cube faces specified with individual files with -list option
                 positive x, negative x, positive y, negative y, positive
z, negative z
                 Use -output option to specify filename
           Cube faces specified in one file.  Use -file to specify input
filename

What steps will reproduce the problem?
1. convert the attached dds file to a tga using NVTT

What is the expected output? What do you see instead?
A nice picture without artifact. I see a vertical black line in the center
of the picture. This artifact is not present with other DDS readers.

What version of the product are you using? On what operating system?
Latest svn checkout (revision 18).

Please provide any additional information below.
Note that the test.dds is flipped along the x axis, just happens to be this
file.

This will prevent dependencies on specific versions of the CUDA runtime.
Since NVTT is designed to be included in third party applications, these
applications might be using a conflicting version of the runtime. To
resolve this issue, libraries and plugins should use the driver API instead.

The Texture Tools library does not have documentation.

This weekend I started writing a tutorial in the wiki:

http://code.google.com/p/nvidia-texture-tools/wiki/ApiDocumentation

I plan to finish it for the 1.0 release.

The texture tools are written in C++. That makes it difficult to use them
from C or any other language that relies on C for its bindings, like
blitzmax, lua, mono, etc.

Non power of two mipmap generation requires the use of a polyphase filter
for high quality results. Currently NVTT implements a polyphaser box filter
as explained here:

http://developer.nvidia.com/object/np2_mipmapping.html

However, higher quality filters are not implemented. An efficient
implementation would cache the the kernel for each phase and reuse them for
each row (or column).

I'm not sure what's the best way of doing that in CUDA, though.

as suggested at
http://developer.nvidia.com/object/newsletter_tip_archive.html#21 you can
get nicer results if you sharpen some mipmap levels after they are
generated (this functionality was available in the old Texture Tools).
Artists on my game want to use the "Sharpen soft" filter for some mipmap
levels (which is available in the Photoshop DDS plugin). 

What steps will reproduce the problem?
1. Use __SSE1__ define (remove __SSE2__) when compiling the library
2. Execute compression on an AMD Athlon CPU
3. Outputed files are invalid

What is the expected output? What do you see instead?
Instead of normal DDS compressed images the output is filled completely
with one color or it almost look like the desired output but with different
color tone and strange lines on it.

What version of the product are you using? On what operating system?
Version: Nvidia texture tools 2 Alpha
OS: Windows XP SP2 32bit

This includes:
- Add support for input images in fp16 and fp32 formats.
- Add options for floating point clamping and quantization (simple tone
mapping).
- Add support for floating point output, RGBE, and other encodings.

Support for DXT1a has been requested by many developers. It should be easy to 
add by using the 
weighted compressor. Need CUDA implementation of weighted cluster fit 
compressor.