PVRTexTool major flaws

  1. The PVRTexTool premultiplies alpha into the rgb channels. I’m encoding single channel textures that happen to have an alpha channel of 0. Even though I set -alpha Image0001.png,a to force alpha=1, but apparently the data has already been lost. This is on OSX. I suspect you’re not passing the correct flags to OSX when you decode the image.

  2. rgb*a,a. 100 x 0,0. <- tool is loading and doing premul

  3. rgb*a/a, a. 000, 0. <- lost the data in conversion back from premul

  4. rgb,1 <- -alpha sets a=1 (but really now 000,1 should be 1001)

Also this will result in lower precision than the original image even for RGB and RGBA images. I don’t have -l on the command line (premul option).

  1. When ASTCMxN,UBN,sRGB mode is used, the colors of my PNG are blown out to super bright (they’re RGB color space). The only thing this should do on an image is set the SRGB_ALPHA version of the ASTC constant into the KTX file. This should have no affect on the imported pixels.

These two bugs make the PVRTexTool unusable for any kind of production work. It’s a very useful tool with a lot of great options. I supposed ImageMagick could be used to force the alpha to 1 before it hits PVRTexTool for the 1/2/3 channel case. That won’t fix data loss in the 4 channel case with alpha that are within 0 to 1.

Since -red/…/-alpha apparently set the value after the premul load, you can use the copied image with alpha set to 1 (to get past premul load), and then use -alpha originalImage.png to set the alpha from the original.

Hi,

can you provide a bit more detail about what you are trying to achieve? Are you converting formats?

bests,
Marton

No, I’m just trying to encode png textures with alpha to ASTC.

  1. PVRTexTool appears to be loading the png image with OSX system libraries with the wrong flags and premultiplying the data, and then unpremulyiplying it. So dilated colors in small alpha regions (f.e. 0) are changed/lost.

PNG is an unpremultiplied format, but textures should be encoded as is regardless. There is a flag to premultiply the texture to knock out pixels in low alpha, but I’m not setting that.

  1. PVRTexTool must be passing -srgb to the ref. astcenc. That doesn’t do what people think, and causes an srgb to linear conversion to occur. That is probably why brightening of the resulting image occurs.

Hi Alec,

Thanks for bringing these to our attention.

For the first issue you mentioned, could you provide the command line arguments you were using and the input files? I’ve tried to reproduce this but I can’t see any alpha pre-multiplication happening.

The second issue is a known bug in PVRTexTool. The problem here is that it always assumes images (PNG, BMP, TGA etc.) are linear RGB, so when you specify sRGB in the format for the output, it does a colour space conversion before transcoding the data.

You could specify lRGB to prevent this conversion, but then you’ll have the wrong ASTC constant in your KTX file.

This is a flaw in PVRTexTool and we aim to fix this in the near future.

Thanks
Lawrence

Hi Lawrence,

Are you testing on OSX for the premul issue? I switched to lRGB already, but then the format constant is wrong as you stated.

Hi Alec,

There is no OS specific code within PVRTexTool itself that would trigger the pre-multiplication. My guess is that it’s happening within one of the image libraries we are using.

Is the input image a PNG file? If you can attach an image file that reproduces the issue that would help greatly.

Lawrence

1 Like

Hi Lawrence,

I think what I was seeing (now that PVRTexTool works) is is that PVRTexToolGUI displays channels unmultiplied (which looks really wrong with all RGB=white, A8). Xcode displays content premultiplied which is more what you’d expect to see. So in the tool you see the channels, and in Xcode the alpha=0 knocks out the channels (but they’re still there). I could see the channels in PVRTexToolGUI. I’m still seeing the sRGB problem in 2008_R1.

There also are command line options for -cube and -array (or both), but nothing for -volume in the tool. The big difference on volume textures is the interpolation between faces. Often times the volume mips are unused with areas like color grading, since volume mips are their own strange beast. Many renderers may not honor ASTC 3D volumes, which is another problem, and expect a 2D array of ASTC encoded textures.

Here is two years later.

I believe 4.23 never outputs srgb constants when requested, and erroneouly applies srgb-to-linear conversion and then encodes that when ASTC4x4,UBN,sRGB is tacked onto the formats. It never converts back to sRGB before the encode, so the data isn’t correct. But it does output the pixels correctly provided you don’t resquest sRGB.

Now what I’m seeing in 4.24, is I think this erronous srg-to-linear conversion is applied whether or not you request sRGB output or not. So now all our textures when dark. Are you telling png importers to do sRGB to linear conversion on import, and then not doing it back before the encode?

I think given that none of the output from this tool is being tested for validity (or in PVRTexToolGUI) and the length of time they’ve been broken that I’ll simply move to Cuttlefish now. It seems to build mips correctly, handle sRGB, and offer all of the options PVRTexToolCLI does including BC support. I hope for those still using this tool that you can correct these input/output issue here and in the GUI tool.

Here’s 4.24-nosrgb (incorrect) and 4.23-nosrgb (matches png) on the right for the same image.
image

I’ve include the png source below.
AttribSimpleGlowHalf