A reliable workflow
Keep each processing stage independently testable
The processing library is independently implemented and testable: source decoding, scalar preparation, gradients, vector operations, and export remain separate layers.
How the browser tools transform image data
Height and image tools turn selected luminance or channel data into a scalar field, calculate Sobel or Scharr gradients, and encode normalized tangent-space vectors. The viewer, converter, and combiner instead decode existing normal vectors before inspecting or changing them.
What the previews and exports are designed to show
The 2D channels, movable-light 3D preview, seam grid, and edge heatmap help diagnose direction and continuity. Lossless PNG exports retain the calculated pixels, while the destination renderer still determines tangent basis, compression, mipmaps, and final shading.
Why these tools are built around inspection
NormalMapGenerator.net is designed for a complete normal-map decision, not just a download button. The tools expose luminance choice, gradient filter, edge policy, vector convention, channel inspection, movable lighting, seam views, and lossless export because each stage answers a different question. Processing an image in the browser keeps the source pixels in local application memory, while visible controls make the transformation reproducible. The site explains where image evidence ends so an estimated normal map is not presented as a calibrated scan or a substitute for a tangent-aware geometry bake.
How accuracy and limitations are handled
The implementation separates decoding, scalar preparation, gradients, vector decoding, conversion, combination, preview, and export so important operations can be tested independently. Documentation is written around observable checks: a neutral vector, an asymmetric groove, a moving light, opposing tile edges, or a destination import setting. Results still depend on source quality, browser decoding, mesh tangents, UVs, compression, and renderer behavior. NormalMapGenerator.net therefore favors lossless files, explicit conventions, primary software references, and plain limitations over claims that every generated texture will be physically accurate or production-ready.