PVRTexToolGUI should display texel values underneath even on unselected views

The hover and channels display (even thought checkmarks are hidden) is he most useful part of PVRTexToolGUI. But channel values are only displayed in the “Colour” panel if the image window is currently selected. I shouldn’t have to select the image window when I have 8 images up on-screen and I’m just comparing pixel values in one pixel to another. It also throws off using this, since color values are displayed for whatever pixel you were last on in the selected view (even though you are hovering over a new value in another image). This coupled with the erroneous sRGB display really makes it hard to verify if any image content is correct. I know the sRGB issue will be fixed in 20.2 when that releases.

Also an option to not premultiply alpha would also be welcome. Especially with ASTC LA for normals where they are stored as rrrg or gggr, it would be nice to swizzle them back and regen the z-value. Then the encoded version could be compared against the original png.

Hi alecazam123,

Thanks for your feedback, it is really appreciated.

The Tools Team have confirmed in 20.2 the new UI will show the currently hovered pixel value at the bottom of the image viewer so you’ll have the functionality available.

Regarding the option to not premultiply the alpha channel, could you please shed some light about it? I’m not sure if it is about avoiding any color space conversion when preparing the image for display.

Right now when decompressing ASTC textures any swizzle is always set to RGBA. Would the normal map regeneration proposal be combined with the no-alpha premultiplication to show the original normal map values?

Best regards,
Alejandro

You should try to import all data as is. Then do any srgb <-> linear, and premultiplying and swizzling and conversions at the shader level. That way these are all fast.

So I may have data as premul alpha, and want to undo it.
Or I may have data as unmul, and want to see it as premul.
Or I may have multichannel data, which should never have premul. Each channel is unique.

For srgb, I may or may not want to apply the conversion to linear.
And then ability to turn off/on channels post-swizzle like you have now.

Similarly normals may be snorm, but I want to view them unswizzled and unsigned (f.e. ASTCnm as rrrg or gggr), and then have z reconstructed from unswizzled xy values. And n.xy * 0.5 + 0.5 to turn them unsigned. BC5 and etc2rg would not need to be unswizzled, but astc often does.

Hi alecazam123,

Many thanks for your feedback, it is really appreciated. I’ll make sure the Tools Team analyses your proposals and will come back to you with an answer.

Best regards,
Alejandro

Hi alecazam123,

Many thanks again for your valuable feedback. I’ve reviewed your proposed pipeline with the Tools Team, and they’ll take your ideas into account for the future.

Currently some parts of PVRTexToolGUI are already ported to GPU like the cube map view but in most of the cases the gain of going from CPU to GPU does not seem to be big enough. The transformations applied are mostly simple allowing a fast enough user experience, you can always provide your feedback if you think this is not the case.

Regarding the uses you mentioned for this new pipeline for premultiplied/not premultiplied alpha, currently you can apply a pre-multiply alpha transform and undo it if you want to, and also toggle the alpha channel in the viewer. For the swizzling, the ASCT decompressor unswizzles to RGBA, not doing any changes after that. For the colour spaces, 20.2 UI will allow to switch the viewer between linear or SRGB.

For the normal maps, there’s a new feature Tools Team is considering to implement in the future: The user would be able to specify some equation to apply to the pixel data, covering any normal map operation required. Would that solve your normal map visualization requests?

Best regards,
Alejandro

© Imagination Technologies Limited. All rights reserved.
Privacy PolicyTerms & ConditionsTrademarksCookies