Summary: With "Attempt to use hardware accelerated scaling" enabled, jAlbum writes thumbnails and scaled images from the unrotated pixel grid for any source whose EXIF Orientation tag is not 1. jAlbum's own metadata layer reads the orientation correctly and emits the rotated dimensions into the generated HTML, so the skin lays the image out as a portrait while the file itself is landscape — the image renders squashed and on its side. Turning the option off fixes it completely.

Environment
jAlbum 39.6 and 39.7 (both affected)
Windows 11 Pro 25H2, OS build 26220.7872, 64-bit
Intel Core i7-13700KF, 32 GB RAM
NVIDIA GeForce RTX 4070, driver 32.0.15.9144 (4 December 2025), display 3840x2160
Skin: Tiger 8.3.0 — but this is skin independent; the wrong pixels are in the generated AVIF files
Output format: AVIF, quality 60, speed 6
Scaling method: Smooth / STANDARD, sharpen 25
Image bounds 2000x2000, thumbnail bounds 490x245
HiDPI thumbs and images off
acceleratedScaling=true

Steps to reproduce
Take a JPEG straight from a camera that records rotation in metadata rather than in the pixel grid — e.g. 6000x4000 pixels with EXIF Orientation = 6 (rotate 90° CW).
Settings → Images → Advanced → tick "Attempt to use hardware accelerated scaling".
Build the album with Force processing on.

Actual result
The generated files use the unrotated 3:2 landscape grid, while the HTML declares the correct portrait dimensions:

File EXIF Generated thumb Generated slide Declared in HTML
IMG_3695.JPG 6000x4000, Orientation 6 368x245 2000x1333 width="163" height="245", card class portrait
IMG_3696.JPG 6000x4000, Orientation 6 368x245 2000x1333 width="163" height="245", card class portrait
IMG_3683.JPG 6000x4000, Orientation 1 368x245 2000x1333 width="368" height="245", class landscape — correct
7M1A8599_DxO.jpg 3840x5760, Orientation 1 163x245 1333x2000 correct

So the metadata read is right and only the scaling/writing path is wrong. The browser then squeezes a landscape image into a portrait box.

Across one 325-image album the split was exact:

293 images with Orientation 1 — all correct
32 images with Orientation 6 — all 32 wrong
Expected result

Thumb 163x245 and slide 1333x2000, matching the dimensions jAlbum itself writes into the HTML.

Workaround / bisect
Untick "Attempt to use hardware accelerated scaling" and rebuild with Force processing → all 32 images correct (thumb 163x245, slide 1333x2000). Verified on 39.7 + Tiger 8.3.0.
Upgrading 39.6 → 39.7 alone does not fix it.
The same album's 2025 edition contains one Orientation 6 image whose thumbnail was generated by 39.3.2 on 26 March 2026 with the same acceleratedScaling=true setting, and it is correct (163x245). So this looks like a regression introduced somewhere between 39.3.2 and 39.6, in the accelerated path specifically.

Notes

Because the HTML carries the correct portrait dimensions, the fault is invisible in the project settings and only shows up on the rendered page — which makes it easy to publish a whole album before noticing. It might be worth having the writer assert that the output dimensions match the orientation-corrected source dimensions, and fall back to the software scaler when they disagree.

Thanks for reporting. Because there are so many JPEG flavors, please pass me a zip of a 1-image project that demonstrates this behavior.