[XnView MP 1.11.5] Specific PNG/JPEG file displayed stretched horizontally

[FredM78]

XnView MP version: 1.11.5 [10169] (June 29, 2026 build)
OS: Windows
Description:
A specific image file (originally a JPEG, 500x769 px, 24-bit color depth) is displayed heavily stretched horizontally in XnView MP — both in the file browser thumbnail and in the full viewer. This is not a "wave/ripple" distortion, but a uniform horizontal stretch.
The file's dimensions and properties reported by Windows Explorer are correct (500x769, 300 DPI, no corruption indicators).
Steps to reproduce:

Open the attached file in XnView MP (browser or viewer).
Observe the horizontal stretching.

Troubleshooting already performed:

The file displays correctly in: web browser, MS Paint, IrfanView, and Windows Explorer/Properties preview. The issue is isolated to XnView MP.
Tested all 3 "DCT Method" options (Integer, Fast Integer, Float) in Settings > Read > JPEG — no change.
Manual zoom (100%, in, out) does not fix the display — rules out a scaling/fit-to-window bug.
Re-saved the file as PNG (via Paint) — the exact same stretching persists, ruling out a JPEG-decoder-specific issue (e.g. chroma subsampling/MCU block rounding).
Restarted XnView MP completely (verified no background process), moved the file to a different folder, and renamed it — none of this affected the bug, ruling out a path/name/cache-based issue.
Out of ~1450 other images browsed in the same XnView MP session, none show this issue — it is specific to this single file.
Key finding: Resizing the image in Paint by even 1 pixel (height), then resizing it back to the exact original dimensions (500x769) and re-saving, produces a new file that displays correctly in XnView MP. This strongly suggests the bug is not related to the file's dimensions/aspect ratio, but to the specific pixel data / byte pattern of the original file — likely a stride/row-width calculation bug in the rendering engine that is triggered by a particular data pattern rather than by file size alone.

Attachments:

original_buggy.jpg — the file that reproduces the issue
repaired.jpg — same dimensions, re-saved via Paint, displays correctly (useful for byte-level comparison)

[user0]

use 'Set DPI...' to fix 72x300 dpi