Image Flip & Rotate

Rendering order, precisely: given the original image at its natural width `w` and height `h`, and a chosen rotation angle in degrees, the angle is first converted to radians (`rad = angle × π / 180`). The new canvas dimensions are then computed with the standard rotated-rectangle bounding-box formula and rounded up (`Math.ceil`) rather than to the nearest integer, specifically to guarantee the box is never a fraction of a pixel too small due to floating-point rounding, which could clip a single row or column of pixels at the edge: `newWidth = ceil(|w·cos(rad)| + |h·sin(rad)|)`, `newHeight = ceil(|w·sin(rad)| + |h·cos(rad)|)`. Once the canvas is sized, the drawing itself uses four chained canvas transforms applied in this exact order: first `translate(newWidth / 2, newHeight / 2)`, moving the origin to the center of the new, larger canvas; then `rotate(rad)`; then `scale(flipHorizontal ? -1 : 1, flipVertical ? -1 : 1)`; and finally `drawImage(image, -w / 2, -h / 2, w, h)`, which draws the original image centered on the (now transformed) origin. Because canvas transforms compose as a single matrix rather than being applied as separate sequential passes, the flip and the rotation always combine correctly and consistently regardless of which one a user toggles first or last — there's no ordering dependency from the user's perspective, only in the fixed order the code applies them internally. Worked example, verified by hand: a 400×200 image rotated by exactly 90° gives `cos(90°) ≈ 0`, `sin(90°) = 1`, so `newWidth ≈ |400×0| + |200×1| = 200` and `newHeight ≈ |400×1| + |200×0| = 400` — the canvas becomes 201×400 in practice (the dimensions swap, as expected for a quarter turn, plus a single extra pixel of harmless padding from `Math.ceil` rounding up a floating-point value like 200.00000000000003, which is never exactly zero in binary floating-point at 90°). The same image rotated by 45° gives `cos(45°) = sin(45°) ≈ 0.7071`, so both `newWidth` and `newHeight` come out to `|400×0.7071| + |200×0.7071| ≈ 424.3`, rounded up to 425 — the bounding box becomes a near-square shape roughly 425×425, visibly larger than either original dimension, which is exactly the extra space needed so the tilted rectangle's corners don't get clipped. At 0° and 180°, the trigonometry reduces back to essentially the original width and height, landing one pixel over (400×201 rather than an exact 400×200) for the same floating-point reason — always rounding up rather than to the nearest integer means this tool would rather waste a single imperceptible pixel of transparent padding than risk clipping a real edge. The quick 90°/180°/270° buttons don't set an absolute angle — each press adds that many degrees to whatever the current angle already is, wrapped back into the 0-360 range with a modulo operation, so pressing "Rotate 90°" three times in a row lands on 270°, and a fourth press wraps back to 0°. The free-angle slider and the number field both read from and write to that same underlying angle value, so adjusting one always keeps the other in sync. The output is intentionally fixed to PNG regardless of the source image's original format, since PNG is the only one of this toolbox's supported formats that can represent the transparent corner triangles a non-90-degree rotation produces without silently filling them with an opaque colour.