I’ve just downloaded and installed the new Nvidia Texture tools and am evaluating the standalone exporter. My usage is converting files to DDS BC1 / DXT1 - mostly, photoshop PSD or layered TIFF.
I’ve noticed that the standalone tools loads (and saves) the Photoshop files I’m testing with some sort of gamma / colorspace correction that makes all the images I tested so far too bright. Comparing to the Photoshop Plugin, I can see a visible difference in the brightness.
I’m using photoshop with monitor color. as far as I understand the subject, no color profile is being attached to the files I’m creating.
Is there anything I can do to get the standalone tool to ignore whatever it is that’s making the images too bright?
I uploaded a test file to my google drive.
https://drive.google.com/open?id=1HvfT88CYXZVyhqeM-qyq2lOIH2DSs5yW
and here is what the standlaone vs. plugin looks like on my computer.
Hi Michael,
Thanks for finding this! This is a bug - it looks like 2020.1.1 (which introduced some colorspace fixes for other file formats) also mixed up how it interprets the color space of Photoshop files without color space management. This should be fixed shortly.
To work around this for the moment, you can specify the Photoshop color profile directly - in Photoshop, go to Edit > Assign Profile… and then choose “Working RGB: sRGB IEC61966-2.1” (or choose the sRGB IEC61966-2.1 profile under Profile: if sRGB isn’t your Photoshop’s Working RGB). This shouldn’t affect how the image appears on screen, but after saving the file back out, nvtt_export should load it correctly.
Hope this helps!
Thanks for the quick and helpful reply!
Hi Michael,
We just released version 2020.1.2 of the NVIDIA Texture Tools Exporter at https://developer.nvidia.com/nvidia-texture-tools-exporter, which should fix this issue - could you try it out and let me know if it works for you? (It seems to load testpattern.psd correctly on the developer machine, but would be good to get confirmation as well!)
Thanks!
It works well! thank you for this very fast turnaround.
I hope I can use this to ask another question -
I’m trying to use NVTT as a command-line tool in my pipeline, to convert source files to DDS files with minimal or no user intervention. In the legacy tool (nvdxt) there was an option to allow the tool to automatically determine the type of compression to use, based on the existence of an alpha channel in the source file. Is there a similar option in NVTT? I can always code something in myself, so it’s not a big issue if there isn’t. Just wondering.
Hi Michael,
Thanks!
In the previous version of the plugins, this would switch between setting the default texture format to BC1 (4 bits per pixel) or BC2 (8 bits per pixel) based on whether there were any non-opaque pixels in the image. However, it was also a bit of an unusual option - here’s why: BC1 also supports transparency, but 1-bit (the new version has BC1a, which allows for transparency, and BC1, which ignores transparency, but both are implemented in the BC1 texture format).
At the same time, BC2 isn’t the best choice for a format with transparency - when you have 8 bits per pixel, BC3 gives higher-quality transparency, and BC7 gives a much higher-quality image overall. But at the same time, although BC7 has the highest quality for a four-channel BC format, it might not be supported by older readers as the format was only introduced in D3D11 (2009). So, since the decision of which texture format to use now mostly depends upon how many channels your image has, how many bits per pixel your budget allows for, and whether or not you’re compressing for a GPU that natively supports ASTC, we decided to remove this checkbox since it’s too easy for it to make a suboptimal texture format choice (for transparent textures, BC2 isn’t as good as BC3, which isn’t as good as BC7, which old readers might not support) - I figure in these ambiguous cases it’s better to have you choose which format you want and to help to give info about the different formats, rather than to have the plugin guess.
Hope this helps!
Neil,
I wonder if you could use the same fix you did for PSD, but also for Layered TIFF files. Addingthe same test file in that format, it seems to exhibit the same brightness issue the PSD did.
thanks!
https://drive.google.com/open?id=1Xcz2D6y6Cg0RGlsBu0iGF-SnRrrDc3Sc
Hi Michael,
Thanks - I think this should be fixed in 2020.1.3 now! Incidentally, we also wound up switching from OpenImageIO to FreeImage, so the entire standalone image importer and exporter just changed. (The reason for doing this was because FreeImage imports images without premultiplication by default, while OpenImageIO imports images with premultiplication by default, which winds up zeroing RGB values for fully transparent pixels. Some OpenImageIO readers do support a flag that makes them read unpremultiplied images, but this seems to interact incorrectly with linear and sRGB color spaces at times).
