Hi,
If i use the tool to compress a png image of 8x8 pixels, the result is wrong. I can see it by using analyze and compare options. I attach the image used for the test.
(very small png)

In file EtcBlock4x4.cpp, line 88 (and many other files and methods) there is call to constructor of that class.
This call does not changes current object (this), instead it creates a temporary object and calls constructor for it, so this call doesn't have effect that you expect from it.

Sorry for my bad English.
BR, Leon.

It will be nice if this tools supports also arrays of images (similar with PVRTexToolCLI)

Code for determining output file format is incomplete - ETCTool always saves output in KTX format. Procesing of file format Format::INFER_FROM_FILE_EXTENSION in EtcFile.cpp has no proper implementation (actually, it just has a todo at line 19).

In the README.md file under Setup For Linux, we are told to "Invoke cmake to create the make files". Being unfamiliar with cmake, it took me a while to figure out that one is supposed to issue the command "cmake .." here. Would you please update the README file?

In Image::~Image, the code to free m_paucEncodingBits is commented out. Presumably this is because one of the Image::Image constructors allows the caller to pass in their own encoding bits so calling delete[] would be unsafe in this scenario. However, in other codepaths, the class allocates it's own m_paucEncodingBits in the Image::Encode function which is never freed.

A possible solution would be to add a bool to Etc::Image to track whether or not it allocated m_paucEncodingBits, and free when necessary.

Currently a block needs to reference an Image, which makes writing Unit Tests touch way more code than it should be.

The mkdir call is being made with unquoted path arguments causing paths with spaces to break the directory creation.

EtcTool.cpp(824)
old:
sprintf_s(strCommand, "if not exist %s %s %s", path, ETC_MKDIR_COMMAND, path);
fix:
sprintf_s(strCommand, "if not exist "%s" %s "%s"", path, ETC_MKDIR_COMMAND, path);

Given Apple's recent announcement, are there any plans to support mac arm64 library building?

What is a correct way to compress normalmaps?
From reading readme it looks like something like "-normalizexyz -errormetric normalxyz -format RGB8" should work better than "-error metric rgba". But with this errormetric I get some artefacts: https://ibb.co/dyL4dk (left is a source image, center is "-normalizexyz -errormetric normalxyz -effort 50 -format RGB8" and right is "-errormetric rgba -effort 50 -format RGB8").
Source image for tests: https://ibb.co/gkTqJk

As the previos issue (#20) was closed, opening this one with a better explanation of the desired feature.
As far as I understant, ETC2 supports the ETC1 specification subset.

Would it be possible to compress ETC2 textures as ETC1, as in, less quality/modes but having the benefit of alpha support, R and RG formats, etc. so compression speed can be increased in exchange for quality?

Thanks!

I posted two times, you closed the issues #21 and #20 and did not even bother to read what I write when I answer you..
I will use bullet points to make sure this time you read them.

• NEED TRANSPARENCY, R and RG COMPRESSION Please get this into your head before answering I need to go and find a ETC1 compressor.
• NEED OPTION FOR FASTER INITIAL COMPRESSION SPEED I was just suggesting that, as ETC2 is backwards compatible with ETC1, to just optionally compress in ETC1 WHILE KEEPING SUPPORT FOR TRANSPARENCY, R and RG CHANNELS, WHICH ARE ETC2 FEATURES STILL NEEDED FOR THIS

Thanks a lot for your time, sorry for using caps and re-posting the issue, but I hope this time the message is clearer.

Do most people really have float image data to feed into an encoder? Shouldn't this take png files containing data and compress them like all of the other tools.

I also don't see EAC_RG11 support, but there is EAC_R11. The former is useful for normal maps which only have two uncorrelated channels.

When I tried my first file conversion with EtcTool, all I got was "couldnt find a place to put converted images". Looking in the source code, I found this is because EtcTool expects to find a slash in the output filename. It would be nice if something like
EtcTool infile.png -output outfile.etc2
worked.

ETC2Comp is still slow compared to other texture compressors, even at effort 0 (effort > 0.5 is pretty much unusably slow). For a 2048x2048 in a AMD A8 takes 20 seconds. Squish takes less than one for BC compression.

Is there any chance to add a faster but less quality mode? This way user can pick which textures he/she wants in higher quality manually later.

How to output pkm? Thanks

I have textures that have an alpha channel that represents data other than opacity. For example part of the model is colorized with a predefined color in the shader according to the texture alpha channel.

Now if the alpha value is 0 (no colorization in my example case) the RGB values are not valid anymore after the compression.

this doesn't make sense.

Got a math-related error while building with vcpkg: install-x64-linux-dbg-out.log

Hi,
Can I use mipmaps generated by myself as input? I may apply "alpha to coverage" to my mipmaps or generate mipmaps from some other filtering methods. If not, can I get from later version? thx

I don't know if this is artifact of copy-pasting the A8 code over to form the R11/G11 calculators. This library seems to be treating incoming channel data as 8-bit for R11 and RG11 encoding. Also constant tables seem to be pre-divided by 255.0f. This means the higher precision of these modes may not be preserved, since the library takes full float unorm data in as input.

This may be an artifact of the ETC2 format storing the base in 8-bits, but I'm trying to lower up the iteration count by computing error in integer space, so I scale some other terms bye 2047.0f.

In CaclculateR11/G11 source:

if (isSnorm)
{
m_fRedBase = (fBase * 255) - 128; // TODO: why 255, shouldn't this be * 1023 - 1024
}
else
{
m_fRedBase = 255.0f * fBase; // TODO: * 2047.0f?
}

I'm using EtcTool to compress rectangular, power of 2 images (2048x1024) with mipmaps for use in WebGL. WebGL Refuses to load the textures when one of the mipmap-based minFilters is selected.

The generated KTX file contains mipmaps from 2048x1024 down to 2x1. WebGL seems to require a 1x1 mipmap.

I've changed this in my fork and the textures now load correctly. The changes are trivial. If there's any interest, I can try to create a pull request, although my open source contribution skills are rusty

There is an internal inconsistency in the handling of m_boolPunchThroughAlpha here that triggers with the RGBX error metric.

We could probably fix it fairly easily, but there's little indication that pull requests are being accepted here anymore. Is there a fork that's actively maintained?

Hi guys, sometimes i have a crash in the EtcTool.

I reviewed the code and i found a char array with a bad size.

In the EtcTool.cpp in function ProcessCommandLineArguments
if (pstrOutputFilename[c] == ETC_PATH_SLASH) { c++; ptrOutputDir = new char[c]; strncpy(ptrOutputDir, pstrOutputFilename, c); ptrOutputDir[c] = '\0'; CreateNewDir(ptrOutputDir); break; }

The ptrOutputDir variable has a bad size, the must be c+1, i changed my code to:

if (pstrOutputFilename[c] == ETC_PATH_SLASH) { c++; ptrOutputDir = new char[c+1]; strncpy(ptrOutputDir, pstrOutputFilename, c); ptrOutputDir[c] = '\0'; CreateNewDir(ptrOutputDir); break; }

And now all run right.

Thanks,

Ruben

The Godot engine is using this, and there's some code in EtcBlock4x4Encoding_RGB8.cpp and EtcBlock4x4Encoding_RGB8A1.cpp that has multiple loops with very large values.

iMaxRed2 = 252645152, iMaxGreen2 = 252645152, iMaxBlue2 = 252645152

            for (int iRed2 = iMinRed2; iRed2 <= iMaxRed2; iRed2++)
            {
                for (int iGreen2 = iMinGreen2; iGreen2 <= iMaxGreen2; iGreen2++)
                {
                    for (int iBlue2 = iMinBlue2; iBlue2 <= iMaxBlue2; iBlue2++)
                    {

After several minutes iRed2 was only at 15/252645152. I've attached the file I was trying to import:

Importing just the red and green channels is fine, but importing all of them results in a near-infinite loop.

This code looks suspect, but I'm not sure if that's by design or not:

		int iMaxRed2 = iColor2Red + (int)a_uiRadius;
		if (iMaxRed2 > 15)
		{
			iMinRed2 = 15;
		}

Several if statements check the max value, then set the min value. Should they be setting the max value to 15 instead?

The source seems formatted a bit unconventional. Is there a clang format present?

I test a 1024*1024 png image, the project run fine , the compresion formate is RGB8, file formate is pkm, But it cost 8 senconds.
But now i have 100000 image to do like this, so how to improve the speed. I use the "mali Texture compresion tool v4.3.0 " with fast mode , it only cost 1.7 sconds.

Documentation states that number of jobs by default is 1. However, when checking the source code, there is a macro definition called MIN_JOBS setting that value to 8.

So when etc2comp is run with parameters -jobs x (x > 0 and x < 9) etc2 spawns 11 threads. And when x > 8, thread count increases linear as expected.

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.