score
score copied to clipboard
Every process flips images vertically on Mac OS with the Metal API
To reproduce
-
Open Score, create a new project
-
Create a Window device use the Device Explorer -> a video window opens
-
Drag and drop and image on the canvas, connect the output to the Window device using the inspector
-
Play -> The image is flipped vertically
-
Add a "Flip V" process at the output of the image process, connect its output to the Window device
-
Play -> The image is still flipped vertically
-
Add a "Flip H" process at the output of the Flip V process (or the image process), connect its output to the Window device
-
Play -> The image is now rotated 180°
I also created a no-op process, with this fragment:
void main() {
vec2 normSrcCoord;
normSrcCoord.x = isf_FragNormCoord[0];
normSrcCoord.y = isf_FragNormCoord[1];
gl_FragColor = IMG_NORM_PIXEL(inputImage, normSrcCoord);
}
Every time this process is applied the input is flipped vertically. Applying it an even number of times is a no-op.
Bug found on Mac OS M2, pre-compiled DMG, version 3.1.11 downloaded from https://github.com/ossia/score/releases/tag/v3.1.11 It only exists when using the Metal backend. The OpenGL backend doesn't have this bug.
The above behavior can be explained by every image-process flipping the image vertically no matter what the processing is:
- Flip V becomes a no-op
- Flip H becomes "Flip H+V", which is a 180° rotation
- A no-op process is a vertical flip.
thanks, yes this is actually a thing I haven't managed to fix properly yet in the general case - OpenGL, Vulkan, Metal and D3D all have:
- different coordinate systems for input textures
- different coordinate systems for output attachments
- different coordinate systems for NDC
see e.g. https://github.com/gpuweb/gpuweb/issues/416
there's some work to do in ISF filters so that depending on the backend, IMG_NORM_PIXEL & friends get the pixel in the "right" direction... and even then I'm not sure that would fix the multipass case if there are some direct texture reads