A photograph can be turned upright while its thumbnail and body still use different size assumptions. I followed the actual display code to understand why baseline and displayed dimensions were kept separate. Small synthetic sizes and the existing scaling module let me examine that relationship without making a new photograph.
Separate a new image from a new way to display it
Re-saving a file was not the only way to stand a sideways photograph upright. The selected display-orientation function reads a reviewed angle from a registry and applies metadata to a photo record. It contains no operation that opens the original image and writes rotated pixels. That keeps the decision about presentation separate from preservation of the original material.
I did not open photographs to determine new orientations in this run. I reviewed historical orientation and phase-review records alongside current display code. Retouching that requires a new image belongs to another flow. A display turn must not be counted as completed retouching, and reading the code must not become a claim that the original site photographs were newly inspected.
Record when raw size and display size diverge
The orientation registry supplies an angle only for entries marked checked; otherwise the function uses zero. Its accepted values are zero, ninety, one hundred and eighty, and two hundred and seventy degrees. A quarter turn swaps the displayed width and height while retaining the baseline dimensions as raw_width and raw_height. Identical-looking size fields therefore have different responsibilities.
For a synthetic 1200 by 800 baseline, a ninety-degree turn creates an 800 by 1200 display box. Passing only the baseline's landscape classification to later layout code could choose a wide layout for an upright portrait result. The earlier gallery article explained why displayed orientation participates in pair eligibility. This article follows those dimensions further into body and thumbnail presentation.
An angle alone does not finish the frame calculation
The body renderer uses display dimensions to select portrait styling and a frame ratio. For quarter turns it sets the image element's horizontal scale to display height divided by display width, with the reciprocal vertical scale. The CSS centers the element and rotates it. Applying scales of one and a half and two thirds inside an 800 by 1200 display box reconstructs a 1200 by 800 element before that rotation.
This is a reading of the selected renderer and CSS, checked with numbers. It is not evidence that a real browser produced the same appearance after image loading. I also observed the condition omitting the ordinary srcset string on the rotated path, but did not turn it into optimization advice for every site. The article describes the presentation contract used by this code.
Use the same orientation basis for a small thumbnail
The thumbnail function calculates the smaller of ninety-four divided by display width and fifty-three divided by display height. It uses that scale for the displayed frame and uses baseline dimensions for the inner image element. A synthetic 1200 by 800 baseline turned ninety degrees therefore yields a displayed thumbnail roughly 35.33 by 53. Calculating from the baseline landscape ratio would produce a different box.
I reused the existing annotation module's contain calculation for this small cross-check. It receives a declared, already-oriented synthetic size and the whole region, then computes a size fitting within a 94 by 53 viewport. Its centered margin coordinates are not claimed as measured positions in the original thumbnail DOM. What is reused is the scale calculation for declared sizes; actual page placement needs its own observation.
Explore the implementation
Actual calculation record for a synthetic quarter turn
{
"geometry": {
"raw": {
"width": 1200,
"height": 800
},
"rotation_cw": 90,
"display": {
"width": 800,
"height": 1200
},
"element_scale_x": 1.5,
"element_scale_y": 0.6666666666666666
},
"thumbnail_box": {
"x": 29.333333333333332,
"y": 0,
"width": 35.333333333333336,
"height": 53
},
"thumbnail_scale": 0.04416666666666667,
"pixels_rotated": false,
"raw_annotation_coordinates_transformed": false,
"browser_rendering_checked": false
}An orientation decision is separate from a phase correction
The loading function reads fresh JSON before applying orientation, phase review, area metadata, selection and retouch presentation in sequence. A selected test checks that a phase correction retains a ninety-degree angle and distinct review provenance. Correcting a photograph's before-or-after classification and correcting its displayed up direction are decisions in separate records.
That ordering does not establish that repeatedly mutating the same already-transformed dictionary is safe. The independent helper here creates a new result from baseline dimensions and an angle each time. Its checks include repeated calls from the same baseline and returning to zero. Those are properties of the new example, not results from testing every repeated-application condition in the original program.
Reuse the existing module and expose only the added calculation
quarterTurnGeometry is an independent metadata helper written for this article. Sizes are integers from one to ten thousand and the angle is one of four permitted turns. It returns copied baseline dimensions, display dimensions and pre-rotation element scales without modifying the input. It neither reads files nor rotates an image and is not an installed replacement for the original photo code.
I downloaded the existing public ZIP, matched its bytes and hash, and ran its fifteen extracted checks. Eighteen additional checks cover the helper and its use with the existing contain calculation. Five illustrative output records are not additional tests. The new helper can be copied from this article; the linked older ZIP contains the annotation and scaling module. The helper has not been added to that older ZIP.
Explore the implementation
New independent helper, without pixel or annotation rotation
// Independent metadata calculation only. Does not rotate image pixels or points.
export function quarterTurnGeometry(raw, rotationCw) {
if (!raw || Object.keys(raw).sort().join(',') !== 'height,width') throw Error('raw size fields');
if (![raw.width, raw.height].every(n => Number.isInteger(n) && n >= 1 && n <= 10000)) throw Error('bounded integer size');
if (![0, 90, 180, 270].includes(rotationCw)) throw Error('quarter-turn angle');
const swapped = rotationCw === 90 || rotationCw === 270;
const width = swapped ? raw.height : raw.width;
const height = swapped ? raw.width : raw.height;
return { raw: { ...raw }, rotation_cw: rotationCw, display: { width, height },
element_scale_x: swapped ? height / width : 1,
element_scale_y: swapped ? width / height : 1 };
}
Screen checks remain after the size calculation
Correct dimensions do not establish that an actual photograph is upright or that its scene is the intended one. EXIF interpretation, pixel rotation and rotation of annotations expressed in baseline coordinates are outside this helper. Passing an unrotated region into the existing coordinate module would violate the example's premise. An integration must align the orientation basis of dimensions and regions together.
The original photographs, review registry, retouch outputs and customer site were unchanged by this work. No rendered-screen or mobile interaction inspection was performed. I find code with those boundaries more useful to a later maker. Checking the small calculation that preserves baseline dimensions helps avoid changing evidential material or unrelated review decisions while correcting presentation.