Why a 360 Panorama Looks Distorted Until You Render It Correctly

Terry Beer — Thu, 12 Nov 2026 11:10:28 +0000

A panoramic image can look completely broken when opened in a normal image viewer.

Walls appear stretched. Straight lines bend. Objects near the top and bottom seem unusually large. And the left and right edges may look like two unrelated parts of the scene.

Yet the same image can look perfectly natural when viewed inside a 360° panorama viewer.

The difference is not necessarily image quality. It is how the image represents space.

If you're building tools for virtual tours, architectural visualization, AI-generated environments, or interactive product experiences, understanding this distinction can save you a surprising amount of debugging time.

The problem starts with how we store a sphere

A typical photograph represents a limited field of view projected onto a flat rectangle.

A full 360° panorama has a different requirement: it needs to represent every horizontal viewing direction, along with the space above and below the camera.

One of the most common ways to store this information is an equirectangular projection.

Instead of storing a conventional camera view, an equirectangular image maps spherical coordinates onto a rectangle.

The horizontal axis represents longitude, while the vertical axis represents latitude.

For a complete panorama:

Horizontal coverage: 360°
Vertical coverage: 180°
Typical aspect ratio: 2:1

A 4096 × 2048 image is therefore a common example of an equirectangular panorama.

But this format has an important consequence.

The image is not designed to be viewed as a flat photograph.

It is designed to be mapped back onto a sphere.

Why objects become stretched near the poles

Imagine standing inside a room and looking directly upward.

In the real world, a relatively small region of the ceiling may occupy a large portion of your upward field of view.

In an equirectangular projection, however, the pixels near the top and bottom of the image represent areas that converge toward the poles of a sphere.

Those regions are stretched horizontally when displayed as a rectangle.

This is a property of the projection rather than a rendering bug.

The relationship between spherical coordinates and pixel coordinates can be expressed as:

function sphericalToPixel(
  longitude,
  latitude,
  width,
  height
) {
  const x = ((longitude + Math.PI) /
    (2 * Math.PI)) * width;

  const y = ((Math.PI / 2 - latitude) /
    Math.PI) * height;

  return { x, y };
}

Here, longitude ranges from -π to π, and latitude ranges from -π/2 to π/2.

The function maps those angular coordinates to pixel locations in the panorama.

The reverse transformation is just as useful:

function pixelToSpherical(x, y, width, height) {
  const longitude =
    (x / width) * 2 * Math.PI - Math.PI;

  const latitude =
    Math.PI / 2 - (y / height) * Math.PI;

  return { longitude, latitude };
}

These transformations become useful when implementing panorama viewers, placing interactive hotspots, or converting between coordinate systems.

Rendering an equirectangular image in Three.js

The easiest way to understand a panorama is to render one.

In Three.js, we can create a sphere, place the camera at its center, and map the panorama texture onto the sphere's interior.

Here's a minimal example:

import * as THREE from "three";

const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(
  75,
  window.innerWidth / window.innerHeight,
  0.1,
  1000
);

const renderer = new THREE.WebGLRenderer({
  antialias: true
});

renderer.setSize(
  window.innerWidth,
  window.innerHeight
);

document.body.appendChild(renderer.domElement);

const geometry = new THREE.SphereGeometry(
  500,
  64,
  32
);

const texture = new THREE.TextureLoader().load(
  "/panorama.jpg",
  () => renderer.render(scene, camera)
);

const material = new THREE.MeshBasicMaterial({
  map: texture,
  side: THREE.BackSide
});

const sphere = new THREE.Mesh(
  geometry,
  material
);

scene.add(sphere);

camera.position.set(0, 0, 0);

function animate() {
  requestAnimationFrame(animate);
  renderer.render(scene, camera);
}

animate();

The important detail is:

side: THREE.BackSide

Normally, a sphere is rendered from the outside.

For a panorama viewer, we're standing inside the sphere and looking outward at its interior surface.

Rendering the back faces makes the texture visible from that position.

In a production application, you'd also implement pointer or touch controls to change the camera's orientation.

The camera itself generally remains at the center of the sphere. What changes is the direction in which it looks.

A 2:1 image is not automatically a valid panorama

This is an easy mistake to make.

Suppose you take a normal photograph and resize it to 4096 × 2048.

The result has the correct dimensions, but it does not suddenly contain a complete spherical environment.

It still represents the original camera's limited field of view.

Similarly, cropping a wide landscape photograph into a 2:1 rectangle does not turn it into a true 360° panorama.

A proper panoramic environment needs consistent directional information across the entire image.

That means the left and right boundaries should connect, the perspective should be coherent, and the top and bottom should represent the appropriate regions of the scene.

This becomes especially important when working with AI-generated imagery.

A generative image model may produce something that looks panoramic in a flat preview while failing when rendered onto a sphere.

The seam problem in generated panoramas

One of the most noticeable issues in generated 360° images is the seam.

Because the horizontal axis represents a complete 360° rotation, the left and right edges represent adjacent directions in the real world.

The image should therefore wrap continuously.

If a wall begins at the left edge, its continuation should appear at the right edge.

If the colors, geometry, or lighting differ too much across that boundary, the viewer may reveal a vertical discontinuity.

A simple pixel comparison can help identify potential problems:

function calculateSeamDifference(
  imageData,
  width,
  height
) {
  const data = imageData.data;

  let totalDifference = 0;

  for (let y = 0; y < height; y++) {
    const left = (y * width) * 4;
    const right = (
      y * width + width - 1
    ) * 4;

    for (let channel = 0; channel < 3; channel++) {
      totalDifference += Math.abs(
        data[left + channel] -
        data[right + channel]
      );
    }
  }

  return totalDifference / (height * 3);
}

This calculates the average RGB difference between the leftmost and rightmost columns.

It is not a complete seam detector.

Two columns can have similar colors while containing misaligned objects, and minor pixel differences can be visually acceptable.

Still, the metric can serve as a useful first-pass diagnostic when processing multiple panoramas.

For more reliable detection, we can extend the comparison to neighboring columns, gradients, and structural features.

AI generation adds another layer of complexity

Traditional panoramic photography usually captures multiple overlapping views and stitches them into one spherical image.

AI-generated environments approach the problem differently.

Instead of recording the geometry of an existing space, a model attempts to synthesize a coherent visual environment.

That introduces several possible failure modes:

Inconsistent architectural geometry between directions
Duplicated furniture or objects
Changes in lighting across the panorama
Distorted ceilings or floor regions
Visible discontinuities at the horizontal seam

These problems are particularly noticeable in architectural visualization.

A room may look convincing in one direction but reveal a misplaced doorway or inconsistent wall geometry after rotating the camera.

When experimenting with AI-assisted workflows, tools such as AI360 Generator offer a way to generate 360° panoramic imagery from a single image. The resulting panorama can then be inspected in a spherical viewer to evaluate continuity, projection quality, and whether the scene works for the intended visual presentation.

The useful distinction here is between generating an image that looks panoramic and generating an environment that remains convincing when explored interactively.

Those are different quality requirements.

Build a small validation step before publishing

Whether your panoramas come from cameras, stitching software, or generative models, a basic validation pipeline is worth implementing.

You don't need a complicated computer vision system to catch the most obvious issues.

Start with a few predictable checks.

1. Validate image dimensions

function validatePanoramaDimensions(
  width,
  height
) {
  if (width <= 0 || height <= 0) {
    return {
      valid: false,
      reason: "Invalid image dimensions"
    };
  }

  const ratio = width / height;

  return {
    valid: Math.abs(ratio - 2) < 0.01,
    ratio,
    expectedRatio: 2
  };
}

This checks whether the dimensions are consistent with a full equirectangular panorama.

It doesn't prove that the image contains valid spherical content, but it can catch an incorrectly sized export.

2. Inspect the horizontal seam

Compare the image's left and right edges.

For batch processing, record the average difference as a diagnostic value.

Avoid treating a single fixed threshold as a universal pass-or-fail rule. Different environments have different lighting and texture characteristics.

3. Render the result interactively

This is the most important step.

A flat image preview cannot reveal every projection problem.

Open the panorama in a spherical viewer and inspect multiple viewing directions.

Pay particular attention to:

The left/right wraparound boundary
Straight architectural lines
Repeated objects
Ceiling and floor geometry
Consistency of lighting across the scene

An image may pass every simple pixel-level check and still look wrong once the viewer starts rotating.

4. Validate the actual delivery environment

Finally, test the panorama where users will see it.

A large equirectangular texture may work on a desktop GPU but cause performance or memory problems on some mobile devices.

Check loading behavior, texture resolution, browser compatibility, and interaction responsiveness.

The final asset should not only look correct. It should work reliably on the devices you're targeting.

Why this matters beyond virtual tours

The same principles apply to several kinds of applications.

In architectural visualization, panoramas allow clients to explore a proposed interior from a fixed viewpoint.

In interactive product experiences, spherical environments provide spatial context that ordinary photographs cannot.

In games and WebGL applications, panoramic images can serve as backgrounds or environment references.

And with generative AI, they provide a way to explore synthesized environments without manually modeling every object in 3D.

But all of these use cases depend on the same underlying requirement: the image must represent directions coherently.

A visually impressive rectangular image is not enough.

Final thoughts

A 360° panorama is more than a wide photograph.

It's a representation of spherical space stored in a two-dimensional image.

Once you understand that distinction, many common problems become easier to diagnose.

The stretched ceiling isn't necessarily a broken image. The visible seam isn't merely a cosmetic issue. And a 2:1 aspect ratio isn't proof that an image contains a valid 360° environment.

For developers building panorama workflows, a practical starting point is simple: validate the dimensions, inspect the seam, render the image on a sphere, and test the actual user experience.

The goal isn't just to generate a panorama.

It's to create an environment that still makes sense when someone looks around.

Tags: #threejs #webdev #ai #javascript

I built a browser-based spectrum analyzer because I wanted something simpler

Terry Beer — Tue, 15 Sep 2026 09:36:09 +0000

A while ago, I just wanted to do something simple: drop in an audio file, see the frequency spectrum, find suspicious peaks, and move on.
But most tools I found were either 🖥️ full desktop apps, 🧱 more complicated than I needed, ☁️ uploading audio to a server, or just felt a little outdated.

So I started wondering: why can't this just run entirely in the browser?
That question turned into Online Spectrum Analyzer: 👉 https://onlinespectrumanalyzer.com

🔒 Keep the audio local

The main idea was simple: your audio shouldn't need to leave your device just to calculate an FFT. Modern browsers already have the Web Audio API, so the whole flow can stay client-side: audio file → decode locally → analyze → visualize.
No account. No mandatory backend upload. I also added 🎙️ microphone input, so you can inspect live audio directly.

📊 The FFT was the easy part

Getting frequency data wasn't really the hardest part. Making it readable was.I spent more time than expected tweaking FFT size, smoothing, frequency scaling, peak detection, low-frequency visibility, and rendering performance.A raw FFT graph can look technical while still being surprisingly hard to interpret. I wanted someone looking for a 50/60 Hz hum to be able to spot it without first studying DSP.

🌈 Then I added a spectrogram

This became one of my favorite parts. A spectrum shows what frequencies exist right now. A spectrogram shows how frequencies change over time.
That makes things like electrical hum, background noise, sudden transients, high-frequency tones, and strange sections of audio much easier to spot visually.
Sometimes a problem is easier to see than to hear.

🤯 The browser is surprisingly capable

This project reminded me how much signal processing can now happen directly in the browser. You already get 🎵 audio decoding, 🎙️ microphone access, 📈 real-time analysis, 🧮 FFT data, 🖼️ canvas visualization, and pretty decent client-side performance.
A few years ago, I probably would've built this as upload → server → process → return result. For this kind of tool, that would actually make the experience worse.

🛠️ What it does now

Right now it supports:

🎧 audio file analysis
🎙️ live microphone input
📊 real-time frequency spectrum
📍 peak frequency detection
🌈 spectrogram visualization
🔒 local browser-side processing

I'm still improving it. One direction I'm interested in is making it more useful for practical audio debugging: hum, noise, clipping, resonances, strange tones, recording issues, etc. Without turning it into a giant DAW.
If you work with audio, Web Audio, music production, podcasting, or browser DSP, I'd be interested to know what you normally look for in a spectrum analyzer.

👉 Try it here: https://onlinespectrumanalyzer.com
Feedback is welcome 🙂

DEV Community: Terry Beer