AVIF Images Embedding With Incorrect Rotation

[Enderm-n]

When uploading AVIF images with rotation metadata to Discord, the embedded image has the wrong rotation. However, JPG images with rotation metadata embed correctly. AVIF images with rotation metadata render correctly when opened in browser.

Rotation metadata can be added to images automatically by avifenc if encoding from a source with rotation metadata present, or by using the --irot option in avifenc.

This DSCF1860scaled50.zip zip file contains an AVIF image which renders with the correct rotation in Firefox and Microsoft Edge. The issue can be reproduced by sending this image, or any other AVIF image with rotation metadata, on Discord. The image should appear with the correct rotation, however the embed appears to ignore the rotation metadata.

Below is an example of how the image renders on discord:

Additionally, here is an example of how the image should appear (converted to jpg to embed)

[onestardao]

looks like this issue is about rotation metadata being ignored in the embed pipeline, not really the same class as RAG/vector ingestion bugs we usually track. in our terminology, it’s closer to a metadata-loss case, but here at the image codec/render layer. curious if you want me to share a checklist we use for metadata consistency debugging?

[Enderm-n]

Hi, yes it may be helpful if you could share a checklist, thank you.

[onestardao]

Hi, it's faster to me to give you whole my idea so I use AI to help me

===

hi, quick follow-up.

what you’re seeing is almost always rotation metadata getting lost before embed. the fix is to normalize or carry the flag all the way. this maps to our “metadata consistency” checks (similar to ProblemMap No.14 bootstrap-ordering) where an upstream step reads the image pixels before orientation is applied.

fast checklist

1. detect orientation on read: check EXIF Orientation for JPEG, and for AVIF check irot/imir boxes (or your decoder’s orientation api).

2. normalize one way only: either

   • transcode to a canonical upright pixel buffer, then clear the orientation flag, or
   • keep pixels as-is and preserve the orientation flag into the embed payload.

3. ensure the embedder consumes the same form you decided in step 2. do not mix.

4. add a round-trip test: read → normalize → embed → display. assert that the viewer and your embed consumer agree.

5. cache bust if you changed normalization rules, to avoid stale rotated previews.

you don’t need infra changes. this is a small semantic firewall at the text/config layer that stabilizes the pipeline.

one-page checklist
See “ProblemMap – Metadata consistency / bootstrap ordering” here:
[WFGY ProblemMap (one-page checklist)]

if you want, i can share a minimal probe that prints the AVIF irot/imir and shows the two safe paths (normalize pixels vs preserve flag).

hi, quick follow-up.

what you’re seeing is almost always rotation metadata getting lost before embed. the fix is to normalize or carry the flag all the way. this maps to our “metadata consistency” checks (close to ProblemMap No.14 bootstrap-ordering) where an upstream step reads pixels before orientation is applied.

fast checklist

1. detect orientation on read: EXIF Orientation for JPEG, for AVIF use irot/imir (or your decoder’s orientation api).

2. pick one path only:

   • normalize pixels to upright, then clear orientation flag, or
   • keep pixels raw and preserve the orientation flag into the embed payload.

3. make the embedder consume the same form chosen in 2. do not mix.

4. add a round-trip test: read → normalize → embed → display. assert viewer and embed consumer match.

5. cache-bust if you changed normalization rules to avoid stale rotated artifacts.

no infra changes needed. this is a small semantic firewall step in the pipeline.

one-page checklist
[WFGY ProblemMap — metadata consistency / bootstrap ordering]

if you need, i can drop a tiny probe script that prints AVIF irot/imir and shows both safe paths.