PVRTextTool GUI can't open its own DXT textures

Just compressed an image into the BC3 (aka DXT4/5, aka S3TC) format and while PVRTexTool happily generates the image, it won’t open the resulting file afterwards. I’ve tried .KTX, .PVR, and .DDS containers, no dice. I’m on Windows and every other program that uses DirectX features works fine, so I don’t think the problem is on my end.

I’ve checked this with version 4.23.0 and version 5.11.1 and loading BC3 textures works on neither.

By the way, it seems like 5.11.1 crashes any time it tries to display a diff. Pretty big feature to be broken, is this only on my end?

Hi YorickECI,

Thanks for your message.

I’ve tried compressing an image in BC3 and opening it in PVRTexToolGUI with the latest internal version of PVRTexTool and everything works fine.

Please raise a ticket in our support website (https://pvrsupport.imgtec.com/) so I can handle you an internal version of PVRTexTool with the issue solved.

Best regards,
Alejandro

The GUI doesn’t seem to open my BC7 KTX textures on Windows that were built with my own encoder. I thought the Windows build had BC support?

Hi alecazam123,

Could you please attach the BC7 KTX texture that is generating the issue? We’ll take a look at it and come back to you.

Best regards,
Alejandro

In the 2020_R2 release of the GUI on macOS (Intel), the BC4/BC5/BC7 textures aren’t opening. Even generating these from an original png with mips, and then trying to re-open these fails with a message about an invalid or unsupported texture format. So far, only BC1 textures opened, but I don’t have BC3 data handy. It looks BC7 encoders are not available either.

Encoding a normal to BC5 snorm, ends up displaying a blank image in the GUI. Changing the range to 0 to 127 then makes the image visible. Maybe this isn’t using the full snorm range. This is the only way that I can view the file, and after saved to KTX, the file won’t open.

Also, the displayed scale of ETC2rg should be 11 bits (+/-2047), but the range displayed is +/-32K. This is a little confusing to compare normals in ETC2rg with ASTC/BC which use 8unorm and 8u/8snorm data. It might be useful here to display the normalized float values instead.

Included a test png image from some of the early id compression demos. This is a normal map that should wrap and display properly as BC5. This can be exported from the GUI tool, but then won’t reopen the file.
collectorbarrel-n

Here’s a ktx generated from the GUI.
collectorbarrel-pvr-n.ktx.zip (30.9 KB)

Here’s a list of few of the found issues with the 2020_R2 GUI release.

  1. PVRTexTool displays colors too bright/dark? srgb? But even normal map colors different from source png?
  2. PVRTexTool can’t decode/display BC4/5/7, only BC1
  3. PVRTexTool can’t encode to BC7
  4. PVR display incorrect 2x2 mips (pixels aren’t correct on BC1). Not a big deal, but checkerboards don’t with BC1 compression don’t display as a checkerboard at 2x2 mip size.
  5. Color evaluation differences when hovering over colors vs. Preview and other viewers. Apple DCM used for comparison, but that uses screen pixels from front buffer and not underlying texture.
  6. 3D textures with no mips aren’t displaying faces properly.

Hi alecazam123,

Thanks for the detailed feedback about the 2020_R2 macOS GUI release. I’ll forward it to the Tools Team for detailed review and will come back to you once I’ve feedback.

Best regards,
Alejandro

Hi alecazam123,

I informed the Tools Team about your feedback for the latest PVRTexTool GUI release (2020_R2). They’re working on all the issues you exposed. They also updated me about some of them.

Regarding encoding a normal to BC5 snorm and displaying as blank image, is it possible the original texture did not have any negative values? if possible, please provide a sample image that reproduces the issue.

For the BC7 format, it is not supported in PVRTexTool.

Regarding visualizing normalized float values in the image viewer, right now it is considered to add a feature to allow the user to select between several options (integer, norm float, etc).

Best regards,
Alejandro