You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Faces: Rename the embed_upscaled column to embed_detail
The value is the share of the crop its source supplied, so 100 means the crop
was not upscaled - which made embed_upscaled read backwards at the one value
worth a clean predicate. The three names now agree: face.EmbedDetail computes
it, SetEmbedDetail writes it, embed_detail stores it. The embed_ prefix stands
for the reason it always did, that the column describes the embedding rather
than the thumbnail its partner thumb_size names.
No shim and no rename migration: nothing has shipped the old column, so
AutoMigrate creating embed_detail is the whole change. A local database that
saw the old name keeps a stale column until it is dropped by hand.
Copy file name to clipboardExpand all lines: internal/ai/face/README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -116,7 +116,7 @@ The on-demand size limit is lifted for the duration of the run (`useMigrationThu
116
116
117
117
Two consequences worth knowing. A warped crop is not interchangeable with a `crop.Sizes` tile, so 112 cannot simply join that table - though a 112 *rectangle* would render as well as `Tile100` if the UI ever wants one. And because the smallest face selects the rendition for the whole file, one tiny face makes every other face in it decode a larger image; that is the lever to measure if embedding cost ever matters, not a crop cache.
118
118
119
-
**`markers.embed_upscaled` says how much of the crop the source supplied**, beside the extent in `thumb_size` that supplied it: 100 is full detail, 1 to 99 says the crop was interpolated and by how much, `EmbedUpscaledUnknown` is a migration that sampled the marker without measuring a ratio, and -1 a marker nothing has sampled. The two columns are written under one condition, so a marker embedded through an endpoint - a reused crop, which reports no source width - records neither rather than one of each. ⚠ The denominator is the crop the embedder was handed, which is the model's 112 px template for an aligned crop and the 160 px `face.CropSize` box for the fallback, so a distribution over the column mixes two scales. It is measured where the crop is taken rather than derived afterwards, because `face.CropSize` and a model's input geometry describe what is configured now and not the vector that was produced. Only the two paths that produce an embedding write it, as with `thumb_size`, and no command synthesizes it. There is deliberately no per-marker warning for an upscaled crop: a default install puts a double-digit percentage of markers in that bucket, so the distribution answers whether it matters and a line each does not.
119
+
**`markers.embed_detail` says how much of the crop the source supplied**, beside the extent in `thumb_size` that supplied it: 100 is full detail, 1 to 99 says the crop was interpolated and by how much, `EmbedDetailUnknown` is a migration that sampled the marker without measuring a ratio, and -1 a marker nothing has sampled. The two columns are written under one condition, so a marker embedded through an endpoint - a reused crop, which reports no source width - records neither rather than one of each. ⚠ The denominator is the crop the embedder was handed, which is the model's 112 px template for an aligned crop and the 160 px `face.CropSize` box for the fallback, so a distribution over the column mixes two scales. It is measured where the crop is taken rather than derived afterwards, because `face.CropSize` and a model's input geometry describe what is configured now and not the vector that was produced. Only the two paths that produce an embedding write it, as with `thumb_size`, and no command synthesizes it. There is deliberately no per-marker warning for an upscaled crop: a default install puts a double-digit percentage of markers in that bucket, so the distribution answers whether it matters and a line each does not.
120
120
121
121
**A marker is stale when its vector, its crop, or its sample extent is.** The first two make it stale because it is in the wrong space; the third because nothing can judge what the vector rests on until the crop is sampled again, and only a re-embedding measures it. Without the third condition a library **already on the target model** is skipped whole - on one reference instance 88,353 of 89,516 markers - which leaves `thumb_size` unset and `FACE_CLUSTER_SIZE` falling back to the detection size the column was added to replace. It is a staleness condition rather than a `--repair` flag for that reason: an opt-in switch reproduces the failure it fixes, a gap nobody knows to close, and `--dry-run` already prices the work before it is paid for. The honest cost is that a re-run against an already-migrated library now has real work to do, once - `entity.ThumbSizeUnmeasured` records a sampling that reached a marker and measured nothing, whether the vector was regenerated or not, which is what makes it once rather than every run. A file that could not be read is left unsettled, because that fault may clear.
0 commit comments