powervr-graphics / Native_SDK

C++ cross-platform 3D graphics SDK. Includes demos & helper code (resource loading etc.) to speed up development of Vulkan, OpenGL ES 2.0 & 3.x applications
https://docs.imgtec.com/sdk-documentation/html/introduction.html
MIT License
702 stars 197 forks source link

[BUG] PVRTexTool 4.24 generates dark textures in linear RGB mode for all formats #59

Closed bulbigood closed 3 years ago

bulbigood commented 4 years ago

Description

Compared to 4.23 and earlier versions, the 4.24 generates darker textures in linear mode. Tested for ETC1, ETC2, PVRTC2. Enabling sRGB mode does not correct the situation, but only makes it worse.

Repro steps

  1. Generate textures with 4.23 and 4.24 PVRTexTool
  2. Compare textures to source image with -diff. Warning! 4.24 --diff says that all is ok, but 4.23 --diff result is different.

Environment

Additional Info

Source texture is RGB .jpg Passed command to generate texture: ./PVRTexToolCLI -i src.jpg -pot -f ETC1 -o new.ktx

PVRTexTool 4.23 --diff results:

omarzohdi commented 4 years ago

Hi, @bulbigood thanks for letting us know. It looks like this issue is related to issue #15. We're currently working to get this fixed for our next release. We'll let you know as soon as we release a fix.

graptis commented 4 years ago

Hi @bulbigood, I did a very thorough internal investigation. I can confirm to you that this is NOT a bug, it is actually the fix of another bug. The results of 4.24 that are not too dark, it is the results of 4.23 that were too bright, as seen in issue #15. However due to an unrelated bug in the viewer (displays textures too dark), it creates the illusion that 4.23 is the correct one.

I tested this using PVRTC and RGBA8 compressions but I am confident that the results are correct because the result of the diff tool completely mirrors yours, and are expected.

The results of 4.24 (REL 20.1) are the correct one. There is an bug in the viewer in both 4.23(19.2) and 4.24(REL 20.1), where it will display textures very dark, but the actual texture data produced is correct in 4.24. Same with the diff tool, the diff you are getting with 4.24 is actually the correct one.

In short: 4.23 may display correctly, but the values contained are actually incorrect (too bright). 4.24 encodes the correct values in the texture, but the viewer (and only the viewer) is too dark.

At this point I would recommend against using 4.23 as you will end up with SRGB values in your shader and this will mess up the shader math. If your engine/application gets too dark or too bright values for 4.24 that means that gamma correction is not applied correctly (or that the texture is loaded with the wrong format, e.g. ETC_SRGB instead of linear or vice versa).

If (and only if) you are using an "old school" rendering pipeline which requires SRGB values in the textures sampled in the shader, I would still recommend producing an sRGB format texture with 4.24 and editing the uploading format to fake that it is linear (e.g. upload a a PVRTCII sRGB as PVRTCII Linear). I recommend against the practice though because it messes up with any lighting equations.

The viewer is due for a complete overhaul and fix in 20.2 which would render the "too dark" problem non applicable.

I am not closing this issue in case you need further details, please close it if you are satisfied that my assessment is correct.

Regards, Gerry

bulbigood commented 4 years ago

Thank you @graptis for detailed info. I gonna check texture processing in my application.

bulbigood commented 4 years ago

I checked my application and returned to PVRTexTool because everything is fine there. Converting from ktx to png shows that image encoded by 4.23 version matches to original. But 4.24 not. Decoder's version doesn't matter. "ktxinfo" tool from KTX-Software says that encoded ktx files are the same. I mean such values as glFormat, glInternalFormat, glBaseInternalFormat and others. I guess encoder of 4.24 applies gamma correction once in linear mode and twice in srgb mode, but KTX header doesn't know about that.

AgileInteractive commented 3 years ago

I use the CLI only. Converting PNG's results in drastically darker PVRTC images for sure in 4.24 (tried to save some different versions of PNG, same with all). I downloaded 4.23 and all is fine. Unfortunately I have no time to test more or give you better information, just wanted to let you know.

omarzohdi commented 3 years ago

Hi all, the issue has been fixed in the 20.2 release. You can download the new version of PVRTexTool here I'll close this issue and if the bug persist please do open a new ticket for PVRTexTool 5.0.0.