Fails to assign OETF for inconsistent cubemap inputs (v4.3 alpha)

[donmccurdy]

When trying to encode a cubemap from PNG to KTX, I attempted to run the command below:

ktx create --cubemap --format R8G8B8_SRGB --assign-oetf srgb px.png nx.png py.png ny.png pz.png nz.png pisa.ktx2

Input files:

pisa.zip

The command fails with an unexpected error:

ktx create fatal: Input image "nx.png" has different transfer function (KHR_DF_TRANSFER_UNSPECIFIED) than preceding image(s) (KHR_DF_TRANSFER_SRGB).

These do indeed appear to be messy files with inconsistent color space data. Unfortunately pretty standard – it'd be really helpful if --assign-oetf could override any inconsistency in the input files. Am I correct in understanding that's the intention for the flag?

[donmccurdy]

For now I've worked around the issue by stripping ICC profiles from each file manually, with imagemagick:

convert nx.png +profile '!exif,*' nx.png

[MarkCallow]

--assign-oetf is intended to override any inconsistency.

A warning may still be in order to let you know you are mixing files with different transfer functions. ICC profiles are a particular issue as they do not contain a recognizable transfer function. So as in this case, the transfer functions may match, the software can't tell. If we do have a warning, probably it should only be issued in non-ICC profile cases.

@vadery what do you think?

[VaderDev]

I think this might be working as intended*. In this case the input formats are different (or there are at least one recognized oetf and at least one unrecognized ICC profile). This check was meant to stop such usage.

But having to rely on an external tool to strip the metadata is not ideal.
We could change this into a warning.

[MarkCallow]

It should be a warning if --assign-oetf or --convert-oetf is specified, an error otherwise. Actually not even a warning in the --convert-oetf case as all images should be properly converted to the same OETF.

[aqnuep]

With --convert-oetf we followed the same convention as the one used by toktx, whereas the source color space is only determined once, for the first image (toktx doesn't re-determine the conversion op for each image either).

Thus supporting conversion from multiple images with different source color spaces will likely be a bit more involving to fix.

Furthermore, I'd note that it would be still important to throw a warning even if using --convert-oetf, as the user may not be aware that the input files they use have different color space data, hence silently converting from different source color spaces could be a potential source of problems.

[MarkCallow]

... (toktx doesn't re-determine the conversion op for each image either).

Oops! Error on my part.

Thus supporting conversion from multiple images with different source color spaces will likely be a bit more involving to fix.

Good point.

Okay. Warning if --assign-oetf, error otherwise. If the above problem gets fixed we can change the --convert-oetf case to a warning too.

[aqnuep]

Sure, I'll look into all of these and come back with a PR. Thanks for letting us know about the issue.