Mobile Camera Orientation Test

Understanding JPEG and Image Orientation Test Behavior Across Platforms

When a cell phone captures a photo, the raw pixel data is always stored as a landscape-format image inside the JPEG file — this is simply how imaging hardware works. To record which way the handset was actually held at the moment of photo capture, the imaging software writes an EXIF orientation attribute into the JPEG's image metadata block. This single integer — one of the 4 orientations: Orientation 0, Orientation 90, Orientation 180, or Orientation 270 — tells any compliant viewer how many degrees clockwise to rotate the pixel data before showing it. All modern web browsers, including Chrome, read this EXIF orientation attribute and rotate the image accordingly, so shots taken in any direction appear correctly oriented when opened directly in a browser or an image viewer. The phone camera flash torch test is free to use with no sign-up, and works on both desktop and mobile browsers.

The problem begins when image processing pipelines strip the EXIF data during photo upload or transcoding. Once the orientation metadata is gone, the browser has no instruction to rotate the pixel buffer and assumes the shot was captured in the normal landscape position — meaning only a horizontally-framed photo will render correctly in photo display, while portrait, flipped-horizontal, and upside-down shots all appear rotated. This is the root cause of the well-documented exif-stripping problem that affects many web publishing platforms and image hosting services. Photo copyright EXIF fields (photo copyright exif) are stripped at the same time, which is an additional concern for photographers.

Display Rotation Values: Orientation 0 Through Orientation 270

Display rotation is formally defined as the counterclockwise rotation of drawn graphics on the panel, which is the opposite of the physical rotation of the unit from its natural orientation. Display rotation values are always multiples of 90 degrees, mapped to the set {0, 90, 180, 270}. The table below shows what these values represent physically and how they correspond to the unit's orientation configuration:

Note that Display#getRotation() from the Android interface returns the counterclockwise rotation, while OrientationEventListener#onOrientationChanged(int) returns the clockwise rotation — opposite conventions that must be handled carefully in your code. The device orientation event in the browser interface (window.DeviceOrientationEvent) exposes orientation data across the x axis, y axis, and z axis, enabling chrome orientation detection and orientation tracking in three-dimensional space for PWAs and web apps.

How to Calculate and Correct Camera Orientation Programmatically: Image Orientation Experiment Formulas

When handling orientations in an Android imaging application built with the camera2 framework, correcting for both sensor orientation and display rotation requires a precise calculation. The general formula for the back-facing unit is:

For a front-facing unit, display rotation acts in the opposite direction relative to the panel, so the formula becomes:

When using the camera2 framework's capture request, you pass this value as JPEG_ORIENTATION to instruct the encoder how many degrees to rotate the output image clockwise. This is how you rotate the output buffers by the correct amount to produce a correctly oriented JPEG. The OrientationEventListener provides the clockwise rotation, while Display#getRotation() provides the counterclockwise value — be careful not to mix the two conventions. Setting JPEG_ORIENTATION in the capture request is distinct from rotating the preview; the former affects the image file, while the latter affects the live preview rendering.

Worked Numeric Example: Aspect Ratio Constraint Logic

Suppose your activity (viewfinder) has a 9:16 aspect ratio (portrait layout on a handset) and your imaging source buffer has a 3:4 aspect ratio. To decide which dimension to constrain when fitting the preview into the viewfinder:

1. Calculate the activity ratio: aspectRatioActivity = (9)/(16) = 0.5625
2. Calculate the source ratio: aspectRatioSource = (3)/(4) = 0.75
3. Apply the condition: Since aspectRatioActivity ≤ aspectRatioSource, the activity is narrower relative to the source.
4. Constrain by width: Set the viewfinder width equal to the activity width, then derive the viewfinder height: viewfinderWidth = activityWidth viewfinderHeight = fracactivityWidthaspectRatioSource

This ensures the viewfinder aspect ratio matches the source dimensions exactly, preventing image distortion or a stretched preview. The viewfinder height and viewfinder width derived this way will always produce a correctly proportioned preview layout. The source dimensions — sourceWidth and sourceHeight — are the authoritative reference for all scaling calculations.

Worked Device Example: Phone in Landscape Mode

Consider a handset with a portrait natural orientation. The imaging chip is mounted with a sensor orientation of 90°. The user rotates the handset 90° counterclockwise into landscape mode, so the display rotation is now 90°. Walking through the correction:

1. Known values: sensorOrientation = 90°, displayRotation = 90°
2. Apply the formula for a rear-facing unit: correctionAngle = 90° - 90° = 0°
3. Interpretation: No additional rotation of the output buffer is needed. The chip's counterclockwise offset and the display rotation cancel each other out, and the image buffer rotation results in a correctly oriented output.

SurfaceView: Simpler Orientation Handling with Automatic Buffer Rotation

The SurfaceView approach is generally recommended for previews when you do not need to process or animate the preview buffer in real time. The Android platform automatically rotates output buffers to match the display orientation of the unit, accounting for both sensor orientation and display rotation internally. This means the preview buffer visible to the user is always portrait when the panel is portrait, and wide-format when the panel is landscape — the platform handles the image buffer rotation for you.

Your primary responsibility when using SurfaceView is ensuring the viewfinder aspect ratio matches the source buffer's aspect ratio exactly. A mismatch produces a distorted preview. The AutoFitSurfaceView class from the Android camera2 samples (available on GitHub) overrides SurfaceView to handle mismatched aspect ratios using a center-crop strategy: it scales the source buffer up until it fills the viewfinder in both dimensions, then clips the overflow using the parent layout params (a RelativeLayout or LinearLayout — note that ConstraintLayout may resize child views rather than clip them, breaking the intended center-crop effect and causing scaled preview artifacts). This output buffer scaling approach maximizes display real estate without distorting the preview aspect ratio.

One important caveat: display rotation alone does not determine the orientation of the source buffer seen by SurfaceView. You must also account for the unit's natural orientation. A laptop orientation differs fundamentally from a handset orientation even at the same display rotation value.

TextureView: Manual Layout for Full Preview Control

The TextureView approach gives you maximum control over the preview rendering but requires significantly more work. Unlike SurfaceView, the Android platform only compensates for sensor orientation when using TextureView — it does not handle display rotations automatically. That responsibility falls entirely on your code. The recommended three-step process avoids the pitfalls of matrix-based approaches (which fail on naturally-landscape units like Chromebooks) and works reliably across Android versions:

1. 1. Set the size of the TextureView to be identical to the preview size chosen. If the preview size chosen is previewWidth × previewHeight, call SurfaceTexture#setDefaultBufferSize(previewWidth, previewHeight) when configuring your capture session, and call View#setLayoutParams to set the TextureView dimensions to previewWidth × previewHeight before calling the buffer size method. Failing to call layout params first introduces a race condition where TextureView invokes the buffer size call with its own measured (incorrect) dimensions. Use the params method with an appropriate ViewGroup container, whether that is a ConstraintLayout, RelativeLayout, or LinearLayout.
2. 2. Scale the potentially stretched TextureView back to the original dimensions of the preview. Because a handset's natural orientation is portrait but the TextureView was set to a landscape-shaped size (previewWidth × previewHeight where previewWidth > previewHeight), the preview appears stretched. Fix this by computing source dimensions and calling the scale methods:
   • If the natural orientation is portrait or upside-down portrait (sensor orientation is 90 or 270 degrees), then sourceWidth = previewHeight and sourceHeight = previewWidth.
   • If the natural orientation is landscape or flipped-horizontal landscape (sensor orientation is 0 or 180 degrees), then sourceWidth = previewWidth and sourceHeight = previewHeight.
   • Apply: setScaleX(sourceWidth / previewWidth) and setScaleY(sourceHeight / previewHeight).
3. 3. Rotate the preview by displayRotation counterclockwise to compensate for the display rotation. Because View#setRotation(float) performs clockwise rotation, pass the negative value: setRotation(-displayRotation). This final step corrects the preview rotation and produces a correctly oriented, scaled preview with no distortion.

The PreviewView component from CameraX in Android Jetpack automates the TextureView layout steps above via its internal PreviewCorrector logic, making it the recommended approach for new imaging application development. The surface buffer size and the coordinate mapping are managed internally, reducing the risk of a stretched preview or incorrect correction on unusual hardware configurations. If you have previously used a raw coordinate-mapping approach for TextureView in your code, note that this method incorrectly assumes a sensor orientation of 90 or 270 degrees and will produce a distorted preview on a naturally-landscape unit such as a Chromebook. Migrating to the three-step process or to CameraX's PreviewView resolves this issue and improves Android 10 support.

Reference Code, Tools, and Documentation for the Camera Orientation Test

The following quick-reference table maps display rotation values to the correction formulas needed for both SurfaceView and TextureView, for a rear-facing unit with a sensor orientation of 90° (typical phone camera):

A condensed code sample showing the three-step TextureView orientation correction using the camera2 framework:

// Step 1: Set TextureView size to match preview size (previewWidth x previewHeight)
textureView.setLayoutParams(new ViewGroup.LayoutParams(previewWidth, previewHeight));
surfaceTexture.setDefaultBufferSize(previewWidth, previewHeight);

// Step 2: Compute source dimensions and scale back to correct aspect ratio
// For portrait/reverse-portrait natural orientation (sensorOrientation = 90 or 270):
int sourceWidth  = previewHeight;
int sourceHeight = previewWidth;
textureView.setScaleX((float) sourceWidth  / previewWidth);
textureView.setScaleY((float) sourceHeight / previewHeight);

// Step 3: Rotate the preview by displayRotation counterclockwise
textureView.setRotation(-displayRotation);

// For JPEG capture: set JPEG_ORIENTATION in the capture request
// (rear camera: sensorOrientation - displayRotation)
int jpegOrientation = (sensorOrientation - displayRotation + 360) % 360;
captureRequestBuilder.set(CaptureRequest.JPEG_ORIENTATION, jpegOrientation);

Key variables used above:

• sensorOrientation — retrieved from CameraCharacteristics.SENSOR_ORIENTATION
• displayRotation — retrieved from Display#getRotation() (returns counterclockwise degrees)
• aspectRatioActivity and aspectRatioSource — computed as width divided by height for the activity and source buffer respectively
• setLayoutParams, setScaleX, setScaleY, setRotation — View methods for layout and transformation
• setDefaultBufferSize — SurfaceTexture method to configure the preview buffer size
• jpeg_orientation — the capture request key used to encode clockwise rotation in the output JPEG

For browser and PWA developers, access orientation data via the DeviceOrientation interface. The window.DeviceOrientationEvent fires continuously as the user rotates their hardware, exposing tilt directions, compass headings, and axis rotation values (x axis, y axis, z axis). You can use these real-time values to drive advanced interactive experiences in navigation apps, interactive games, and augmented reality UIs. Refer to the MDN documentation for DeviceOrientation event for full browser support details and the correct way to request access to hardware sensors in Safari on iOS (which requires an explicit permission prompt). The DeviceOrientation interface is also the foundation for orientation demo implementations in PWAs that support homescreen install.

For Webflow users encountering the EXIF-stripping problem during web publishing:

• Access the responsive image setting using CTRL+SHIFT+O (Windows) or CMD+SHIFT+O (Mac) — this key combination reveals the setting for any selected image component or visual element, implementing a responsive image disabled state for that asset.
• To force-regenerate responsive images after a fix, use CTRL+SHIFT+I to trigger the regeneration process, then republish to apply the changes.
• For images hosted in a content-system-bound rich text block, use right-click settings on the embedded image to access the same control. Note that this may not be available in the Webflow editor for content-system images — use the visual editor instead.
• If you need to preserve photo copyright EXIF fields or image metadata containing orientation data, always verify behavior on the live site (not just in the editor) using the browser in Chrome with DevTools open.

Camera orientation handling is a deep topic that spans mobile photography, web development, image compression workflows, Android app development, and responsive design. Whether you are debugging image flipping on a live site, implementing correct orientation compensation in a camera2 framework capture session, or building advanced interactive experiences powered by the DeviceOrientation JavaScript event, the principles remain consistent: understand which coordinate system each value lives in, apply the correction formula for your specific hardware and platform, and test across a representative range of units — handsets, tablets, laptops, and Chromebooks — in both portrait and landscape modes.

Comments & Feedback