EtcTool encoded sRGB(A) textures don't match source PNG.

[alecazam]

The resulting images from EtcTool are too bright. This likely indicates some sRGB conversion on import, without a conversion back. Typically want to convert to high-precision linear color, build mips, and then convert each mip back to sRGB before the encode, or convert the endpoints ideally after the encode (so that you're fitting to linear and potentially premul colors). PVRTexToolCLI had a similar bug up until v4.24.

I also applied the min job change to 1, rectangular mip fixes, and max color bounding fixed listed as issues elsewhere on this bitrotting project. Timings for EtcTool (supposed to be so fast) are 900s at q70 vs. 44s for -qetcfast with PVRTexToolCLI using etcpack for the 100MB corpus of image that I'm using. I'm assuming 70 is pretty high quality, but this really isn't the fastest encoder in town or we're not using the magic setting for Etc2 textures. I'm assuming this project was abandoned once Android got ASTC support.

[alecazam]

Apart from not applying any srgb conversions to float on imported data before building mips, the constants written out to the KTX files are also not correct. So sRGB(A) data isn't written out with non-SRGB constants. Ugh.

enum class InternalFormat
		{
			ETC2_SRGBA8 = 0x9279
                 }

switch (m_pfile->GetImageFormat())
		{
		case Image::Format::RGB8:
            m_data.m_u32GlInternalFormat = (unsigned int)InternalFormat::ETC2_RGB8;
            m_data.m_u32GlBaseInternalFormat = (unsigned int)BaseInternalFormat::ETC2_RGB8;
            break;
            
		case Image::Format::SRGB8:
			m_data.m_u32GlInternalFormat = (unsigned int)InternalFormat::ETC2_SRGB8;
			m_data.m_u32GlBaseInternalFormat = (unsigned int)BaseInternalFormat::ETC2_RGB8;
			break;

		case Image::Format::RGBA8:
            m_data.m_u32GlInternalFormat = (unsigned int)InternalFormat::ETC2_RGBA8;
            m_data.m_u32GlBaseInternalFormat = (unsigned int)BaseInternalFormat::ETC2_RGBA8;
            break;

		case Image::Format::SRGBA8:
			m_data.m_u32GlInternalFormat = (unsigned int)InternalFormat::ETC2_SRGBA8;
			m_data.m_u32GlBaseInternalFormat = (unsigned int)BaseInternalFormat::ETC2_RGBA8;
			break;

		case Image::Format::RGB8A1:
            m_data.m_u32GlInternalFormat = (unsigned int)InternalFormat::ETC2_RGB8A1;
            m_data.m_u32GlBaseInternalFormat = (unsigned int)BaseInternalFormat::ETC2_RGB8A1;
            break;
                
		case Image::Format::SRGB8A1:
			m_data.m_u32GlInternalFormat = (unsigned int)InternalFormat::ETC2_SRGB8_PUNCHTHROUGH_ALPHA1;
			m_data.m_u32GlBaseInternalFormat = (unsigned int)BaseInternalFormat::ETC2_RGB8A1;
			break;

[alecazam]

Here's a collection of all the fixes that have never landed from various PRs into this tool to fix it. Google, can we get an update to the tool so that people aren't generating bad ETC2 files?

Note that PVRTexToolGUI doesn't display gamma correctly as of 8/16/20. Mali Texture Tools (bitrotting since 2017) cannot open any ETC2 files with sRGB(A) set, but you can view the R/RG11 and non-sRGB format textures. macOS Preview cannot display content and Finder can't display dimensions or thumnails for ETC2 or PVRTC content, so trying to visually verify the output was an unfortunate challenge.

patchToFixETCTool.diff.zip

[richgel999]

I'm assuming this project was abandoned once Android got ASTC support.

Yes, it appears dead.