In image editor, cropping scale gets applied off by 0.4%

[diegomarangoni]

When you scale the crop preview, the editor does not keep the right ratio.

To reproduce this error:

• Upload an image with 4608 x 3072
• On the crop feature, create an selection with 1680 x 560
• Hold shift and scale to fit all image width (4608px)
• The height result was 1544px, that is wrong, the correct is 1536px.

[diegomarangoni]

Tested on MacOS 10.8 with the following browsers:

• Chrome Version 28.0.1500.71
• Safari Version 6.0.5 (8536.30.1)

[alexvorn2]

4608/1680 * 560 = 1536
this is how the number come from...

[diegomarangoni]

Replying to alexvorn2:

4608/1680 * 560 = 1536
this is how the number come from...

I tried with an fresh install of WP and keep having same error.

Tested with Chrome and Safari.

[ericlewis]

Confirmed. Not a big deal, I personally would rather see the whole image editor redone rather than fixing bug after bug found in it.

What the ticket reports

The image editor's crop tool does not preserve the aspect ratio of a selection once it is scaled. With a 4608x3072 image, a selection of 1680x560 scaled to the full image width comes out 1544px high instead of 1536px. A committer confirmed the report in comment 4 and reduced its severity, but the ticket has carried needs-patch since 3.5.

Why it is still valid

The arithmetic is still on trunk. imgAreaSelect stores a crop selection in integer preview pixels, and the preview is capped at 600px (see $sizer = $big > 600 ? 600 / $big : 1 in wp-admin/includes/image-edit.php). onSelectChange() then converts both dimensions back to image coordinates with the same expression:

selW.val( Math.min( imageEdit.hold.w, imageEdit.round( c.width / sizer ) ) );
selH.val( Math.min( imageEdit.hold.h, imageEdit.round( c.height / sizer ) ) );

At 4608px wide the sizer is 600 / 4608, so one preview pixel is about 7.7 image pixels. The library has already floored the preview selection, so dividing it back by the sizer rounds a second time and the locked ratio drifts by up to one preview pixel. Dragging a drawn 3:1 selection to the full width gives a stored preview height of 201, and 201 / 0.1302083 rounds to 1544 - the reported number. The ratio-preserving answer is 1550, and a selection drawn at exactly 219:73 (which is 3:1 in preview pixels) already comes out 1536, which is why the bug is visible only for some selections.

What this changes

The crop tool remembers the ratio imgAreaSelect is actually enforcing when it binds its handlers, and onSelectChange() derives the height from that ratio in image space, rounding once:

height = imageEdit.round( width * parseFloat( ar[1] ) / parseFloat( ar[0] ) );

This covers both ways a ratio gets locked: the values typed into the Aspect ratio fields, and a hand-drawn selection that is shift-dragged. A free-form selection with no ratio in force keeps the previous expression verbatim, so its behaviour is unchanged.

For a drawn 3:1 selection dragged to the full width the result is 1550 instead of 1544. A locked 16:9 ratio now yields 2592 instead of 2588. The ticket's own 1680x560 example produces 1536, which it already did on trunk because that ratio divides the 600px preview evenly.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude
Model(s): Sonnet
Used for: test cases, code review