What an image becomes before it is scored

Before a rating model produces anything, your photo stops being a photo. It becomes a vector - a fixed-length list of numbers - and every step after that operates on the list, never on the image. This is the encoding step, and it is worth understanding on its own terms rather than as a footnote to the score it eventually produces.

A grid of numbers, first

A digital photo is already numbers before a model touches it. Each pixel is a small set of values - typically one number per colour channel, red, green and blue, each somewhere between 0 and 255. A modest photo might be a few million pixels, each with three of those values, which is several million numbers arranged in a grid that happens to look like a picture when you plot it correctly.

That grid is not what a rating model works with directly. It is resized to a fixed shape first - the reasons for that are their own subject, covered in why the model shrinks your photo before it does anything else - and then handed to an encoder. The encoder's job is to turn that resized grid into something much shorter and much more useful: an embedding.

Normalisation, the unglamorous step

Before the grid reaches the encoder's main layers, it usually passes through a small piece of arithmetic that gets skipped in most explanations because it is genuinely boring. Each pixel value is shifted and scaled by fixed constants - typically a mean and a standard deviation computed once, from the dataset the model was trained on, and then baked in permanently.

The effect is to put every input photo on the same numerical footing regardless of how it was originally exposed or white-balanced, which makes the encoder's job more consistent. It has one visible consequence: a photo whose colour statistics sit far outside what the training set looked like - unusual lighting, an unusual colour cast - is being normalised with constants that do not fit it well, and the encoder receives a slightly distorted starting point as a result. This is a real effect and a small one, and it is not the same claim as saying the model cares about your lighting setup - it does not, it just inherited fixed constants from whatever photos it was shown during training.

Feature extraction, in outline

What happens next is a long sequence of learned transformations, each one taking the previous layer's output and producing a new one. Early layers respond to simple things - edges, colour boundaries, local contrast. Later layers combine those into more complex patterns, and later still into patterns that correspond, loosely and inconsistently, to things a person might name.

None of this is stored as a list of labelled parts. It is activation patterns - which of many possible detectors fired, and how strongly - and calling any single one of them "the shape detector" or "the texture detector" is a simplification a person makes after the fact, not a label the network uses internally. What a "feature" actually is, and why the mismatch with human vocabulary matters, is worth its own explanation rather than a paragraph here - see what a "feature" is when a vision model talks about one.

The point that matters for this post is simpler: by the end of this sequence, the several million numbers you started with have been compressed down to a few hundred or a few thousand. That compressed output is the embedding.

What an embedding actually is

An embedding is a point in a high-dimensional space - a list of, say, 512 or 768 numbers, each one meaningless on its own, together locating your photo relative to every other photo the model has ever seen or could see. It is not a thumbnail, not a compressed image file, and not anything you could open and look at. There is no decoder built into a scoring pipeline that turns the embedding back into pixels, because nothing downstream needs one - the scoring head reads the embedding directly, never the photo.

This is also why an embedding is not reliably reversible into the original image. The transformation that produced it discarded information at every layer - not accidentally, but deliberately, because the entire point of training is to keep what predicts the label and drop what does not. Two photographs that differ in ways the model was never trained to care about - a slightly different background texture, a slightly different shade of a wall - can produce embeddings that are nearly identical, because those differences were never worth keeping. That said, reconstruction is not flatly impossible in every case; researchers have shown partial image recovery from some embeddings under some conditions, which is a separate and more technical question worth its own treatment rather than a blanket "it's just numbers, don't worry."

Why the embedding is the length it is

The number of dimensions in an embedding - 512, 768, sometimes more - is a design choice made when the architecture was built, not a figure derived from the photo. More dimensions can hold more distinctions, in principle, but they also mean more parameters to train, more computation per photo, and a higher risk that the extra capacity gets used to memorise quirks of the training set rather than to capture anything that generalises. Fewer dimensions force the encoder to be more selective about what it keeps, discarding more but making what remains more likely to be genuinely useful rather than noise the network happened to have room for. There is no size that is simply correct; it is a trade-off tuned during development, checked against how well the resulting embeddings support whatever task - scoring, search, classification - the model was built for.

How the encoder was trained to produce this at all

An encoder does not arrive at a sensible embedding space by accident. It is trained against an objective that rewards useful organisation - commonly, either a classification task, where the network is pushed to place images with the same label near each other, or a contrastive task, where it is shown pairs of images and pushed to place matching pairs closer together than non-matching ones. Contrastive approaches, of the kind behind CLIP-style models, learn partly by contrasting an image against a large batch of unrelated ones and pushing its embedding away from all of them except its true match, which is a different training signal from ordinary classification and tends to produce spaces organised more by broad semantic similarity than by any single narrow label. Either way, the embedding space is a side effect of solving that training objective - nobody designs the space directly, and its layout is whatever configuration made the objective easiest to satisfy across the entire training set.

Embeddings do not travel between models

An embedding only means anything relative to the specific encoder that produced it. Two different models - even two trained on similar data for a similar purpose - organise their spaces differently, using different dimensions for different things, and an embedding from one is not comparable to an embedding from the other in any direct way. This has a practical consequence worth knowing: if a service retrains or swaps its encoder, embeddings computed under the old one and stored for later use become meaningless under the new one, and any comparison, cache, or "similar to your last upload" feature built on top has to be recomputed from the original photo rather than reused. A score computed from an old embedding and a score computed after a model update are not on the same scale for this same underlying reason, which is the mechanism behind the more general point that a tool's scores can drift across model versions - the version boundary is, mechanically, an embedding-space boundary.

Why nearby points mean similar photos

The training process that produces an encoder is set up, directly or indirectly, to put visually or semantically similar images near each other in this space and dissimilar ones far apart. "Near" here has a precise meaning - usually a measure like cosine similarity, which compares the angle between two vectors rather than their raw distance, and is its own small subject worth a page to itself: see cosine similarity, the one formula behind "looks like".

The practical consequence is that a scoring head never has to reason about a photo from scratch. It only has to learn how score correlates with position in a space that the encoder has already organised sensibly. That is a much easier problem, and it is why the same basic encoder architecture gets reused across wildly different tasks - the encoder does the organising, and a small head on top does the reading. What that read-out step looks like, and why it produces a number rather than a location, is covered separately in latent space, explained with a rating tool in mind and regression head or class buckets.

What this means when you upload a photo

Two photos of the same subject, taken a minute apart, are not the same input to the model in any way that matters here. Different framing, different light, a slightly different angle - each of those moves the resulting embedding to a different point in the space, sometimes by a little and sometimes by enough to matter. This is the mechanical root of something a lot of people notice without having a name for it: why the same subject can score differently across a single afternoon, and the mechanism described there is exactly this step, not anything downstream of it.

It also means that once the embedding exists, the original pixels have already done their job. Some services keep the photo, some discard it and keep only the vector, and those are different retention decisions with different implications - a fuller privacy comparison is not this post's job, but it is worth knowing the embedding is, on its own, already the useful part.

None of this is specific to bodies, penises, or any adult subject - it is how every modern vision encoder works, trained on cat photos and product shots as readily as anything else. Rate Cock runs a version of this same pipeline before it produces a breakdown across its six axes, which is the point where the embedding stops being an abstract vector and starts being read for a purpose - what that read-out step contains specifically is covered on the product side rather than here. The design choice of exposing several scores rather than one figure from that read-out is a different subject again, covered in full elsewhere on this site.

If your actual interest is a physical measurement rather than a model's opinion of a photograph, an embedding was never going to give you one - Measure My Cock's method starts from a tape rather than a vector, which is the honest way to get a number in centimetres. Reading what a resulting score does and does not tell you, once you have one, is its own subject on Penis Rater, and choosing between a model's read-out and a person's is a different comparison again, one Rate Penis covers from the human side.