FA-79250 / Image orientation metadata / Member archive

Metadata stripping counts only for baked uploads · case 05

Stripped but unbaked uploads are predicted to rotate even though no tag survives.

Member previewVariant 5 · 3 implementations · 8 checks per implementation

Case contract

Predict what a browser shows for a photo that went through an upload pipeline. Input {tag, baked, reset, stripped, css, cross_origin}. Baking applies the tag to the pixels; the remaining tag is 1 if metadata was stripped or if baking also reset the tag, else the original tag. The renderer applies the remaining tag when css is "from-image" or the image is cross-origin (image-orientation: none is ignored cross-origin). Finally the viewer applies its own extra orientation (default 1). Orientations are (k clockwise quarter turns after m mirrors), with applying B after A giving k = k2 + (-k1 if m2 else k1). Invalid tags count as 1. Return [shown_tag, shown == tag].

Why this case matters

Camera, phone and scanner images carry an orientation hint separately from the stored pixels; galleries, thumbnailers, editors and upload pipelines must interpret it consistently or photos appear sideways, mirrored or doubly rotated.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixture	Actual	Expected	Outcome
regression: stripped metadata 0	`[5, false]`	`[2, false]`	Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.