ktx encode and create lost --normalize option

[wasimabbas-arm]

Not sure why --normalize was removed from encode and create but its still referred to in the docs within --normal-mode

     --normal-mode      Optimizes for encoding textures with normal data. If the input texture has
                         three or four linear components it is assumed to be a three component
                         linear normal map storing unit length normals as (R=X, G=Y, B=Z). A fourth
                         component will be ignored. The map will be converted to a two component
                         X+Y normal map stored as (RGB=X, A=Y) prior to encoding. If unsure that
                         your normals are unit length, use --normalize. If the input has 2 linear
                         components it is assumed to be an X+Y map of unit normals.
                         The Z component can be recovered programmatically in shader code by using
                         the equations:
                             nml.xy = texture(...).ga;              // Load in [0,1]
                             nml.xy = nml.xy * 2.0 - 1.0;           // Unpack to [-1,1]
                             nml.z = sqrt(1 - dot(nml.xy, nml.xy)); // Compute Z
                         ETC1S / BasisLZ encoding, RDO is disabled (no selector RDO, no endpoint
                         RDO) to provide better quality.

[MarkCallow]

I missed this. @lexaknyazev was this a deliberate omission? If so, why? The normalize code is still in the image processing library.

[MarkCallow]

was this a deliberate omission?

Ping @lexaknyazev. Please respond. Do you have any objection to it being restored?

[MarkCallow]

was this a deliberate omission?

Ping @lexaknyazev. Please respond. Do you have any objection to it being restored?

Ping @lexaknyazev again. I will ask @wasimabbas-arm to restore it. If you have an objection, speak now.

[lexaknyazev]

The spec for the CLI tool had a limited scope so some features were excluded.

To add it now, one would have to go through all currently possible input/output parameter and payload configurations and define reasonable normalization behavior for them or explicitly declare certain combinations invalid.

[MarkCallow]

To add it now, one would have to go through all currently possible input/output parameter and payload configurations and define reasonable normalization behavior for them or explicitly declare certain combinations invalid.

Yes we need to do this. It is mostly about the input I think. For example it should be invalid for any non-linear input.

[MarkCallow]

@wasimabbas-arm IIRC you wrote the normalize implementation for the image library and toktx. The normalize function still exists in the image library which is shared by toktx and the new tools. Therefore please use that experience to draw up a list of input formats acceptable for normalization.

Regarding outputs, although normalize was originally introduced for making 2-component normal maps, I see no reason why use of the function be limited to 2 component outputs. Are there any output formats, currently supported by ktx create|encode for which it would be actively bad to allow normalize to be applied?

[wasimabbas-arm]

@wasimabbas-arm IIRC you wrote the normalize implementation for the image library and toktx.
I did yes. I had a start at this on Friday but didn't get far yet.

I don't fully understand what's the deal with outputs? Normalise only applies to normal input data why does it matter if its 2-component or 3-component output?

[wasimabbas-arm]

By the way, I am not sure if it makes sense to create another issue but looks like we have lost --flip as well. Was that a deliberate decision?

[MarkCallow]

@wasimabbas-arm IIRC you wrote the normalize implementation for the image library and toktx.
I did yes. I had a start at this on Friday but didn't get far yet.

I don't fully understand what's the deal with outputs? Normalise only applies to normal input data why does it matter if its 2-component or 3-component output?

I'm asking if there are any output formats for which creating them from normalized input makes no sense. For example does it make sense if the output is a FLOAT format?

[MarkCallow]

By the way, I am not sure if it makes sense to create another issue but looks like we have lost --flip as well. Was that a deliberate decision?

--flip? Do you mean toktx's --lower_left_maps_to_s0t0? Yes we lost that. I will soon be submitting a PR to add a --texcoord-origin options to ktx encode which provides the same functionality. Perhaps we also need a ktx texcoord-origin command to flip an existing .ktx file.