-
-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad quality for texture compressed with default etc1s
command
#1062
Comments
… webp because it looks terrible after compressing (see issue in description) see issue donmccurdy/glTF-Transform#1062 https://linear.app/needle/issue/NE-3363/usdz-product-progressive-textures-look-crappy
The relevant KTX Software call: toktx --genmipmap --bcmp --assign_oetf linear --assign_primaries none metallicRoughness.ktx2 metallicRoughness.jpg glTF Transform uses default KTX Software settings for the While I'd certainly be interested to learn if you find ETC1S settings that give acceptable results here, it's my opinion that while ETC1S can sometimes give decent visual quality for non-color textures, it often cannot. You may want ETC1S for color textures and UASTC (or traditional image compression) for the rest. I try not to take a strong stance on what optimization steps users "should" choose, but the flags chosen for the all-in-one glTF-Transform/packages/cli/src/cli.ts Lines 319 to 334 in 82a11a3
That's equivalent to what the KTX2 Artist Guide recommends as well — gltf-transform uastc input.glb output1.glb --level 4 --rdo 4 --slots "{normalTexture,occlusionTexture,metallicRoughnessTexture}" --zstd 18 --verbose
gltf-transform etc1s output1.glb output2.glb --quality 255 --verbose |
We're so far pretty happy with the default settings for ETC1S, and the file and GPU size savings are so considerable that they offset the quality in almost all cases. This texture absolutely seems to be an outlier – it's the first time we see ETC1S go so horribly wrong. Yes, there can be artifacts, but not something that looks like 128px downsampling... |
As far as I can see, the ETC1S default settings in the new Khronos glTF Compressor for web are essentially identical to what glTF Transform uses, with one exception — the web app doesn't generate mipmaps, probably because libktx does not support them. If we test the glTF Transform doesn't expose the option to disable mips, though I'm open to doing that. But it'd be great to figure out why mipmaps matter here, and whether that's a bug. Perhaps a bug report on the KTX-Software repository would be a good next step, yes. |
That's great additional info, thanks for checking. I agree that disabling mipmaps is no solution here. So basically the bug seems to be that with mipmaps enabled, the highest mipmap (and all lower ones) change content, whereas an identical highest mipmap to "no mipmaps" would probably be expected. I'll report that to the KTX-Software repo. |
Some additional findings related to gltf.report: it looks like there is an ok-ish mip 0 in the file, but mips degrade very fast. Seems that gltf.report doesn't display mip 0 but instead uses a lower mip (which I think is fine because the displayed image is small), and that lower mip is broken for this file. |
Seems to be nothing we can do on this side, upstream discussion in: |
Do you want to continue the discussion regarding the --assign-oetf command in the ktx-software repo? I'm confused by Mark and your answer collliding, and especially that without the |
Describe the bug
Compressing the metallic-roughness texture with etc1s results in terrible quality
To Reproduce
Steps to reproduce the behavior:
gltf-transform etc1s "Watch.glb" "Watch.etc1s.glb
Expected behavior
Better texture quality 😅
screenshot below is compressed with https://github.khronos.org/glTF-Compressor-Release/ default etc1s settings
Versions:
Additional context
Before compression
After compression
The text was updated successfully, but these errors were encountered: