Math Encoder
A VAE you could fit on a napkin (and why you won't use it)
- pixels
- LATENT
Start with the review the author wrote for you. Open this node's source file and the very first line reads: "These are currently near-useless, but at least they're instant." That's city96 - the GGUF quantization guy, the one who made Flux run on consumer cards - telling you exactly what this is before you spend an afternoon on it. MathEncode (display name "Math Encoder") is a proof-of-concept that encodes an image into latent space with no neural network at all.
What it is
Normally, getting an image into latent space means running the VAE's encoder: a real, trained neural network that costs VRAM and time. MathEncode skips all of that. It takes an IMAGE, shrinks it to an eighth of its size (matching the 8x downsampling the VAE does), then applies a hardcoded per-channel linear formula to approximate what the encoder would have produced. The idea, straight from the README, is that the SD latent space behaves "mostly linearly": change the RGB values by some amount and the four latent channels shift in a roughly predictable way. So city96 sampled that mapping and fit a straight line per channel - a 3x3 matrix plus a bias for each of the four latent channels, stored in linear_weights.json and shipped with the repo. No model loaded, no weights to download, instant.
The inputs and output
There are only three inputs, and this is where it gets a little funny:
pixels- the IMAGE you want encoded.latent_ver- v1 or xl, matching the target model's latent space.mode- an enum with exactly one option, "linear_encoder". It's a stub waiting for future modes that never arrived.
Output is a single LATENT. Wire it into a KSampler as the starting latent and you technically have a math-only img2img.
Why you won't actually use it
The linear fit is a lossy approximation of an already-lossy encoder. It discards everything the real VAE's nonlinear layers capture, so your encoded latent carries less information, and decoding it back gives you something that looks vaguely like your image with the soul removed. The README is equally blunt about the pack's decoders - "proof of concept tier at best," TAESD is better in every way. Same spirit here. If your actual goal is fast or cheap encoding, TAESD is the honest answer. If your goal is correct encoding, use the real VAE encode path.
Install
Identical to the rest of the pack - ComfyUI Manager, search "SD-Advanced-Noise", or:
cd ComfyUI/custom_nodes
git clone https://github.com/city96/SD-Advanced-Noise
then restart ComfyUI. No dependencies beyond what ComfyUI already ships, no model files, Apache 2.0.
The honest take
MathEncode is a museum piece from a fun experiment: can you encode into latent space with algebra alone? The answer is technically yes and practically no. It's worth five minutes of your time because the near-linearity of latent space is a genuinely interesting fact about how these models work - but keep your real img2img workflows on the VAE. This is the node you open to show a friend how latent space behaves, not the node that produces your final image.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| pixels | IMAGE | — | |
| latent_ver | COMBO | 2 options: v1, xl | |
| mode | COMBO | 1 options: linear_encoder |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| LATENT | LATENT | — |