PVRTexTool doesn't produce SRGB textures correctly

[sasmaster]

I have been experiencing a weird bug.I first was sure SRGB setup was wrong in our engine,But it isn't.We compare also with Desktop OpenGL 4.4 env.
Example:
Iphone 6 , OpenGL ES3.0
Created a set of textures from PNG and exported to PVRTC 4bpp RGB sRGB.
Also exported the same set to PVRTC 4bpp RGB linear RGB.
When comparing visuals with either set, the results look exactly the same - they are over exposed.
That means that the space of the textures is not sRGB but rather linear. I made sure iPhone's default Framebuffer has a color format of sRGBA8888 .It all good.Also falling back to non sRGB FBO gets dark results which is fine.
Additionally,as we use your PVR loader API,I checked if the PVR header fetched colorSpace == sRGB.So it does.I also noticed that inside PVRTexToolGUI app,after the export is done, the texture format always shows :" PVRTC Xbpp RGB" but never SRGB.Not sure if it is meant to be like that.Please let me know if you can confirm there is a bug with sRGB space textures .Thanks

[PVRDevTech]

Hi,

When you are using sRGB PVRTC you must specify the correct compressed texture format, which can be one of the following depending on how you have encoded your texture:
COMPRESSED_SRGB_PVRTC_2BPPV1_EXT
COMPRESSED_SRGB_PVRTC_4BPPV1_EXT
COMPRESSED_SRGB_ALPHA_PVRTC_2BPPV1_EXT
COMPRESSED_SRGB_ALPHA_PVRTC_4BPPV1_EXT

If you do not specify the format the implementation will interpret the texture as Linear RGB.

For reference: http://khronos.org/registry/OpenGL/extensions/EXT/EXT_pvrtc_sRGB.txt

Thanks,
Shaun

[sasmaster]

You mean internal format. That's correct. And that's what I am doing after reading the loaded data. Something wrong with the exporter. Both linear and sRGB look the same when rendering

…

On Jun 22, 2017 11:51 AM, "Devlin Techman" ***@***.***> wrote: Hi, When you are using sRGB PVRTC you must specify the correct compressed texture format, which can be one of the following depending on how you have encoded your texture: COMPRESSED_SRGB_PVRTC_2BPPV1_EXT COMPRESSED_SRGB_PVRTC_4BPPV1_EXT COMPRESSED_SRGB_ALPHA_PVRTC_2BPPV1_EXT COMPRESSED_SRGB_ALPHA_PVRTC_4BPPV1_EXT If you do not specify the format the implementation will interpret the texture as Linear RGB. For reference: http://khronos.org/registry/OpenGL/extensions/EXT/EXT_ pvrtc_sRGB.txt Thanks, Shaun — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAawgOWiq8exjujNAFp2QQnvDyeUgJ5Jks5sGir6gaJpZM4OBRZl> .

[sasmaster]

Btw,what is the correct filtering for mipmapped sRGB on PowerVR hardware? I see in your PVR loader SDK you're setting linear and linear_mipmap_nearest for mag and min respectively.Is it correct? In many cases sRGB and linear interpolation doesn't work good.

[PVRDevTech]

Hi,

Would it be possible for you to send over the exported files from PVRTexTool - the linear RGB and sRGB output.

Thanks

[sasmaster]

Archive.zip

the one with "l" suffix is in linear space, the other .pvr is sRGB .Also included the original texture

[PVRDevTech]

Hi,

Could you try the two textures that I have attached and tell me if they look anything like what you would expect.

Edit: When you said that you are using some of the framework, are you using the function pvr::nativeGles::textureUpload by any chance or are you creating the buffer and uploading the texture data yourself?

textures.zip

Thanks

[sasmaster]

Thanks,will try those textures tomorrow. I am loading the textures by myself into memory.From then on we use the logic from your SDK to parse PVR and create GL texture objects.Btw,we use the code from SDK 3.5

[sasmaster]

But I can already tell you, from visual comparison with what you have sent - your textures look much darker.So PVRTexTool does have a bug! Check it out:

The two darker textures are yours.Though both linear and srgb look the same.

[PVRDevTech]

Hi,

We were investigating the issue yesterday, I sent you those textures to determine whether the output is what you were expecting or not (in your application). We are now aware of an issue with PVRTexTool GUI whereby the application is not displaying the SRGB textures correctly, so take the image displayed in the GUI with a pinch of salt as they are not accurate.

Thanks,
Shaun

[sasmaster]

"With a pinch of salt "? Hehe, man I don't get this one. ;) Look, I haven't run those textures you sent thru the engine. Now I am even not sure if they are the "correct sRGB" .They look too dark to me ... I took a look at how the texture should look in Adobe sRGB profile and it looks much brighter. Are those pvr sRGB textures supposed to be that dark? When do you plan to ship a fix?

…

On Jun 23, 2017 12:03 PM, "Devlin Techman" ***@***.***> wrote: Hi, We were investigating the issue yesterday, I sent you those textures to determine whether the output is what you were expecting or not (in your application). We are now aware of an issue with PVRTexTool GUI whereby the application is not displaying the SRGB textures correctly, so take the image displayed in the GUI with a pinch of salt as they are not accurate. Thanks, Shaun — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAawgFqyeR4wxD0pARwi3fbxtuUNTjVUks5sG39kgaJpZM4OBRZl> .

[sasmaster]

Also,what do you mean by this?

We are now aware of an issue with PVRTexTool GUI whereby the application is not displaying the SRGB textures correctly

PVRTool doesn't show them correctly? Or it encodes them incorrectly?

[PVRDevTech]

"With a pinch of salt "?

Don't interpret what you see in PVRTexTool as being accurate was all I was trying to say :)

PVRTool doesn't show them correctly? Or it encodes them incorrectly?

Does not display them correctly, we are not aware of any encoding issues at the moment.

Are those pvr sRGB textures supposed to be that dark?

From what I understand sRGB bias's towards the darker end of the colour scale (to help mitigate banding in darker areas of the image), so I would think an sRGB image would be darker than a linear RGB image as a consequence of the encoding.

Thanks,
Shaun

[sasmaster]

But my initial issue was that the srgb pvr in my engine looked too bright.And even the linear one looked the same.And I state this based on the comparison of rendering that texture performing linearization and gamma correction in the shaders manually.

[PVRDevTech]

Hi,

If you could test those textures in your application for us and let us know how they look, that would help us to verify the issue in the PVRTexTool GUI.

And I state this based on the comparison of rendering that texture performing linearization and gamma correction in the shaders manually.

Are you saying that you are manually performing linearization of the sRGB texture in your shaders? If so then you should set the internal texture format to RGB, otherwise the texture will get linearised twice, once by the hardware and once by your shader.

Thanks,
Shaun

[sasmaster]

Yeah, sure. Gonna test those and let you know. Thanks for collaboration.

…

On Jun 23, 2017 1:11 PM, "Devlin Techman" ***@***.***> wrote: Hi, If you could test those textures in your application for us and let us know how they look, that would help us to verify the issue in the PVRTexTool GUI. And I state this based on the comparison of rendering that texture performing linearization and gamma correction in the shaders manually. Are you saying that you are manually performing linearization of the sRGB texture in your shaders? If so then you should set the internal texture format to RGB, otherwise the texture will be getting linearised twice, once by the hardware and once by your shader. Thanks, Shaun — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAawgLhtnnFprvI3UHGvAqZLZn-L8Bdzks5sG49pgaJpZM4OBRZl> .

[sasmaster]

Hi.Sorry for the delay.Yes,I have tested your texture_srgb.This one results in correct SRGB.See two attached screenshots from iPhone6 test.The brighter one (wrong) uses pvr SRGB 4bpp.The darker one uses your texture_srgb, which looks correct.

[PVRDevTech]

Hi,

Thanks for testing that texture for us, we now know the exact cause of the issue in the PVRTexTool application and have raised a bug with the Tools team to get this fixed.

Thanks,
Shaun

[sasmaster]

Great.Looking forward for the fix.Thanks!

…

On Mon, Jul 3, 2017 at 11:54 AM, Devlin Techman ***@***.***> wrote: Hi, Thanks for testing that texture for us, we now know the exact cause of the issue in the PVRTexTool application and have raised a bug with the Tools team to get this fixed. Thanks, Shaun — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAawgI-KtftuX9RGuXRrPYoECR5ZBybTks5sKKxXgaJpZM4OBRZl> .

[YangAndI]

Hi,
When I call the "cTexture.saveFile()" method, the program complains " public: static unsigned __int64 const CPVRTString::npos" (?npos@CPVRTString@@2_KB) pvr_test E:\test\pvr\pvr_test\pvr_test\pvr_test.obj
"

[alecazam]

sRGB support is still broken in 2008_R1. PVRTexTool should not be applying sRGB conversion, just setting the constants (f.e. with -f ASTC_4x4,UBN,sRGB)

[graptis]

This has been fixed on 20.1 (PVRTextool version 4.24). Unfortunately the viewer will display the textures as too dark, but this is unrelated to the actual values in the textures, which are correct.