Skip to content
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

Proposal: add an ability to Y-flip images during transcode #79

Open
wants to merge 1 commit into
base: master
from

Conversation

@mosra
Copy link

mosra commented Oct 1, 2019

While the encoder-provided option to flip the image during encoding is everything needed when one controls the whole pipeline, it's of no use for general image viewers that have no power over how the input was generated. Having the chance to configure Y flipping during the transcode makes it easier to integrate, as the application doesn't need to worry about patching texture coordinates or doing texture coordinate transform in a shader.

While flipping the compressed image post-transcode is possible, it's a non-trivial amount of work, considering the broad range of target formats supported. On the other hand, when done directly in Basis, flipping can be done on the internal ETC1S representation:

  1. patching the output pointer and making row stride negative, which has very little impact on existing code (apart from making pointer arithmetic work with signed types);
  2. and bit-flipping the selector bits using a modified 3-operation bit reverse trick.

Assuming the encoder's output is reasonably invariant to image flip, this new code path could be tested by comparing these two outputs for equality:

  • flipped PNG -> basis -> target format -> RGBA
  • PNG -> basis -> flipped target format -> RGBA

This was tested on ETC1/2, BC1-7, ASTC and RGBA8 output, however it currently doesn't handle flipping for PVRTC textures, as there's cross-block modulation and I don't have deep enough understanding of the format to be able to code that. Similarly for FXT1 due to a different block size. Treat the code more like a proof-of-concept (and feel free to do anything with it, of course).


At first I thought about just opening a feature request, but then went on to try how feasible this would be, to avoid asking for the impossible :) It's of course entirely possible that I missed some important aspect of the format and it can't work this way -- however if it can, I dare to say the code changes needed won't be so invasive and the additional maintenance/testing effort for this feature is in reasonable bounds.

While the encoder-provided option to flip the image during encoding is
everything needed when one controls the whole pipeline, it's of no use
for general image viewers that have no power over how the input was
generated. Having the chance to configure Y flipping during the
transcode makes it easier to integrate, as the application doesn't need
to worry about patching texture coordinates or doing texture coordinate
transform in a shader.

While flipping the compressed image post-transcode is possible, it's a
non-trivial amount of work, considering the broad range of target
formats supported. On the other hand, when done directly in Basis,
flipping can be done on the internal ETC1S representation:

 1. patching the output pointer and making row stride negative, which
    has very little impact on existing code;
 2. and bit-flipping the selector bits using a modified 3-operation bit
    reverse trick.

Assuming the encoder's output is reasonably invariant to image flip,
this new code path could be tested by comparing these two outputs for
equality:

- flipped PNG -> basis -> target format -> RGBA
- PNG -> basis -> flipped target format -> RGBA

This was tested on ETC1/2, BC1-7, ASTC and RGBA8 output, however it
doesn't handle flipping for PVRTC textures, as there's cross-block
modulation and I don't have deep enough understanding of the format to
be able to code that. Similarly for FXT1 due to a different block size.
@Squareys

This comment has been minimized.

Copy link
Contributor

Squareys commented Oct 2, 2019

This would be amazing, since it would remove the need to flip UVs on WebGL/OpenGL! 🎉

@mosra mosra referenced this pull request Oct 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.