What VP8 gives the analyzer
VP8 is the lossy codec Google built into the WebP container. It compresses frames using a DCT-style block transform plus per-block prediction, then writes side information about block sizes, prediction modes, and a single global color table. That side data is exactly why a brightness-based displacement map works so well — every 8-by-8 block still preserves enough local contrast that, after you run it through sharp().greyscale().extractChannel(0), you ship a clean height field rather than mush.
The reason this matters is that, unlike a JPEG, a VP8 frame keeps more of its high-frequency components inside the budget. When you push the brightness values into a Three.js PlaneGeometry and feed them through a displacementMap, you see ridges, valleys, and the residual noise that compression tried to hide — visible as soft dune-like bumps rather than JPEG’s flat patches. The data behind the geometry is the same data already in the file; the analyzer does not create new structure, it surfaces what the codec preserved.
The displacement scale dial is the whole game
A first-time user tends to load the default displacementScale: 1.25 and call it done. Most of the depth you can extract lives between 0.5 and 2.5. Below 0.5, the surface flattens to a wrinkled sheet. Above 2.5, the same image turns into a spike field where every chroma-noise pixel becomes a needle.
What the scale dial is doing is multiplying the height of every vertex before the lighting pass. Each PlaneGeometry segment has 192 subdivisions by default, which means a 1024-pixel image splits into roughly 200 thousand vertices. Scale at 1.25 keeps tall features readable; scale at 3.0 exaggerates compression noise into geometry. The reason you would ever push past 2.5 is if you are hunting for a specific edge — a printed watermark, a paper texture, a finger smudge — that lives in the highest-frequency band. For most phone photos, scaling higher does not improve clarity, it forces noise that the codec tried to remove back into view.
Segments and texture size are coupled, not independent
The two sliders look independent. They are not. The segments slider controls how finely the plane is divided, and maxTextureSize caps the displacement texture at 512, 1024, 1536, or 2048 pixels on the longest side. A 2048 texture with 32 segments looks like a quilt; a 512 texture with 320 segments looks like a hedgehog. You want the texture resolution roughly equal to or higher than the segment count.
The consequence is obvious once you see it: 320 segments and a 512 texture gives you 6,000 vertices for each texel, which means most vertices never move. Conversely, 32 segments on a 2048 texture wastes four-fifths of the detail. The sweet spot on most phone photos is 192 segments at 1024 texture — the defaults — and the surface stays responsive when you drag to rotate. Push to 320 segments only after you also increase the texture size to 2048, or you pay the rendering cost without gaining any new depth resolution. In benchmarks I have run on a 1080-pixel portrait, doubling segments from 192 to 320 raised vertex count by 75 percent but improved visible surface detail by under 5 percent — the displacement texture was the bottleneck, not the geometry.
What the 3D view shows that the flat file hides
Open the same WebP in two tabs side by side and the question answers itself. The flat image tells you what the picture shows. The displacement view tells you what the picture is. A city skyline turns into a row of staggered cubes with shadow gaps at the rooftop line. A portrait turns into a soft pillow shape with eye-socket depressions that are invisible at flat resolution. A leaf turns into a ridged plate where the veins show up as raised seams.
The reason this works at all is that human faces and natural textures share a property with the lighting signal we already extracted: local contrast carries structural information. Brightness is not just a color; it is a surface normal in disguise. Rotate the analyzer output and the lighting pass by Three.js reveals which bright values were facing the camera and which were tilted away. The geometric story of the picture has been inside the WebP the whole time, and you did not have to recreate it; the analyzer proves it.
When the analyzer is the wrong tool
There is a real class of image where the displacement map is meaningless. Low-contrast gradients — fog, sky backgrounds, washed-out flat scans — give you a flat plane no matter what scale you push to. Photos with strong JPEG-style block artifacts (older digital cameras, screenshots, scanned documents) tile their 8-by-8 structure into the height field as a checkerboard you can see from any angle. Compressed-and-resaved WebPs do the same, which is why I am cautious about feeding anything that has been re-encoded more than twice.
The tool earns its keep on real-world texture photography: bark, fabric, masonry, hand-drawn sketches, printed receipts, even tightly-cropped icons. The smarter use is to take one well-lit photograph with strong oblique lighting, run the analyzer once, and keep the displacement grid as a reusable asset — the surface is a property of the original capture, not of the file format. If you are trying to ship a 3D effect on top of a flat thumbnail, the analyzer reduces the work to a one-step pipeline; if you are trying to recover hidden structure from a low-quality scan, it can save you an hour of Photoshop work. The same displacement grid can also feed procedural material systems — Substance Designer, Blender’s adaptive subdivision, any tool that needs a height map already built for it.
Try the full VP8 Image Analyzer at Elysia Tools; the live VP8 Image Analyzer visualization lets you rotate the rendered surface in the browser without uploading anything.
Most image tools stop at the question of how the picture looks. The VP8 Image Analyzer treats that as the first half of the question and pushes into the second half, which is what the picture is — its surface, its ridges, the geometry the codec decided was worth preserving. The point is that every compressed image carries a low-pass copy of its own height map, and pulling it out takes one grayscale pass and a Three.js plane. What becomes possible, ultimately, when you keep the displacement grid alongside the original? Tactile design tools, synthetic-data pipelines, paper-texture rendering, any workflow where the difference between flat and structured is the whole point.
