This thread is about my SZS tools and especially about the tool wimgt: An optimization of encoding CMPR images is planned. Therefore I need your help and input.

Background

CMPR is a compressed image format divided into blocks (details). A block covers 4x4 pixels. For each block, 2 colors are defined. 2 bits are used for each pixels. There are 2 modes: Without alpha and with alpha support. The discussion here is about the last case.

With 2 bits for each pixel there are 4 possible states, when transparency is enabled:
* Use color1
* Use color2
* Use the middle of color1+color2
* Be transparent.

Because of the 4x4 block, the 2 colors must be chosen by a good algorithm with respect to all colors of the 16 pixels. My iterative algorithm works good. If all pixels of a block are transparent, there is no optimal color setup. In this case, the tools use white (not really planned).

Issue

@Atlas pointed me a problem:

There is a problem when compressing textures to CMPR: if the pixel is set to transparent, your tool will always generate it as a white transparent pixel, regardless of the original transparent color. This is a problem for some textures like the karts, that use transparent black to avoid reflections. When generated with your tool, the texture will look fine on previewers, but if the alpha is used by the purpose I mentioned, they will be white pixels in game. Please fix that

If this is true, the effect of transparent pixel depends on both colors. The issue is now, that a user can't define a default color and that sources with real alpha channels (e.g. PNG with palettes + transparent, RGBA32, ...) are not analyzed for the color definition.

Idea

My idea consists of 3 parts:

1.) The default color for whole transparent blocks is XXX,YYY (color pair must be defined by this discussion).

2.) If a source contains a real alpha channel, the colors for a block are analyzed to find an optimal color pair.

3.) 2 options: One to set the default color pair (e.g. --cmpr-default) and one to force the color pair and override step 2. (e.g. --force-cmpr-color).

Discussion

I want to discuss:
* This issue in general: Dou you have any experience with it?
* Choice of default colors (idea step 1).
* Analysis of the source (idea step 2).
* Name and kind of the options (idea step 3).

I will start with 1 new option:
--cmpr-default=RGB or --cmpr-default=RGB1,RGB2

They define the default colors for the case, if all 16 pixel are transparent. If only 1 color is defined, both colors are identical.

Both colors are converted to RGB565 (c1+c2). The colors are sorted automatically, so that c1<c2. If both are identical, the least significant bit of green (6 bits, red+blue have only 5 bits) is cleared for c1 and set for c2.

If option is not defined, then black (RGB=000000,000400, RGB565=0000,0020) is the default

Done: szs.wiimm.de/changelog.html#r0

Will anyone of you test it?
If yes, tell me your favorite operating system (Linux or Windows) and I will create a test version tomorrow (in ~15-20 hours).

I'm working at arena support for command "wszst DISTRIBUTON" and will release a Beta version tomorrow for Windows and Linux.

First progress: ct.wiimm.de/dis/3 (see battle arenas)

@Atlas and other testers
v2.04a is out. Some changes for --cmpr-default and default color for full transparent CMPR blocks since last notice:

• By default, source is searched to find color pair.
  
• --cmpr-default rgb1[,rgb2] overrides default.
  
• Use --cmpr-default 0 to force black or --cmpr-default -1 to force white.
  

Read szs.wiimm.de/info/mipmap.html#opt (bottom) for option details.