Daniel's been organizing his small-parts drawer again, and this time he wants to train a model on it. The prompt's got two real questions buried in it. First, for a dataset of maybe a hundred phone photos of hardware — screws, bolts, standoffs, the stuff in the sixty-four-part box he built — are there annotation tools that run on Android, or lightweight cloud tools that don't mean standing up Label Studio for a hundred images? Second, if he does gather that data, what's the most logical model to train for catalog-image-in, structured-data-out? Fine-tune a large vision model, or train something small?
And the schema he's sketching is category, title, description, length, plus structured metric and imperial fields. Which is already more thought than most people put into a hundred-image dataset.
He's also asking whether the model can deduce length without him providing it. He's been using the scale-ruler workflow for a while — photograph a part next to a ruler, ask what it is, get back a precise identifier like quarter-inch-long self-tapping screws, six millimeters. That works as an agent workflow. The question is whether it works as a training task.
So let's start with the part nobody wants to do.
The annotation.
Before we get to which model to train, we have to talk about what you're actually feeding it.
The real subject here isn't hardware. It's the smallest viable training task. A dataset you can gather in fifteen minutes on a phone, for a model that does one narrow thing well. And the tension that runs through the whole thing is that the task is trivially small, but the tooling landscape is built for teams labeling a million images, not one person labeling a hundred.
Right. If you're an autonomous-vehicle company, you have a labeling platform with twenty annotators, a review queue, inter-annotator agreement metrics, the whole thing. If you're Daniel with a drawer of screws, you have a phone and an afternoon. The tools don't scale down gracefully. They scale up.
And the gotcha he already named — perspective and scale distortion — that's the technical spine of the data-collection half. Because length is the one field he wants the model to deduce, and length is exactly what a casual phone photo distorts.
Let's get concrete about that, because it matters for how he shoots the hundred photos. A six-millimeter screw photographed at thirty degrees off-axis and twenty centimeters away has a different apparent length than the same screw photographed flat and close. The pixels change. If length is a label the model is supposed to predict, and the training images vary in camera angle and distance, the model doesn't learn the screw's length. It learns the camera setup.
It learns the photographer.
It learns the photographer. And that's the failure mode. So the first best practice for a hundred-image, single-domain dataset is consistency of capture. Same lighting, same background, same distance, same angle. Every photo as close to identical framing as you can manage. That matters more than the number of images.
Which is where the scale-ruler trick Daniel already uses becomes load-bearing. A fixed reference object in frame is worth more than any post-hoc correction. If every photo has the same ruler in the same position, the model has an anchor. It can learn that six millimeters is this many pixels when the ruler says so.
And if he wants the model to deduce length without him providing it, the reference object isn't optional. It's the only thing that makes the task possible. A single image of a screw with no scale reference is a metric-estimation problem, and perspective distortion is exactly what breaks it. You can't recover absolute length from pixels alone. You need either a fixed camera rig or a reference object in frame. That's a data-collection decision, not a model decision.
So that's the capture side. Now the schema. Daniel proposed category, title, description, length, and structured metric and imperial values. Let's walk through that, because there's a real design question hiding in it.
The first thing I'd argue is that the schema should separate what the model must predict from what it can be given. If length is the hard target — the thing he wants the model to deduce — then length should be a first-class field in the annotation, not a substring of the title. If you bury the length inside a free-text title like quarter-inch-long self-tapping screws, six millimeters, the model has to parse the title to extract the length. You're making it do two jobs at once.
And the title-format preservation problem is really a structured-output task dressed as a captioning task. He wants the model to return a precise catalog identifier, always in the same format. That's not free text generation. That's a template with slots.
The schema should encode the title as a template. Category, length, diameter, thread type, whatever the recurring variables are. Then the title becomes a rendering of those slots, not the source of truth. The model learns to fill slots, and the title gets assembled afterward. That's a much easier learning problem than generating a correctly formatted string from scratch.
So the fields he listed are right, but the relationship between them matters. Category is a classification target. Length is a regression target, or a binned classification if he wants to keep it simple. Description is probably the least important field for a closed set of known parts — it's the one place where free text can creep in and make the output unpredictable.
And the structured metric and imperial fields are smart. A screw might be six millimeters in diameter and a quarter inch long, depending on what market it came from. Keeping both as separate fields means the model doesn't have to learn unit conversion. It just reports what it sees.
Which brings us to the annotation tooling question. He asked specifically about Android and smartphone tools. What's the honest answer?
The honest answer is that lightweight, phone-native annotation tools are thin on the ground. Most mobile options are either consumer photo taggers — fine for labeling vacation photos, not fine for structured training data — or thin clients for a desktop or cloud backend. You can do bounding boxes on a tablet in some tools, but for a hundred images of single objects, you probably don't need bounding boxes at all.
That's the key distinction. If the task is one image in, one structured record out, you don't need a bounding-box annotation tool. You need a form with an image attached. That reframing collapses the tooling problem.
Right. A bounding-box tool is for when the model has to find the object in a cluttered scene. Daniel's photos are of individual parts on a known background. The object is the whole image. So the annotation is just a set of fields per image. Category, title, length, metric, imperial. That's a spreadsheet with image thumbnails.
Which means a lot of the heavyweight cloud tools are overkill in a very specific way. Label Studio is immensely powerful — it does bounding boxes, polygons, keypoints, relations, active learning, all of it. But standing it up for a hundred images is like renting a warehouse to store a shoebox. The infrastructure cost isn't in the annotation, it's in the deployment.
And there's a middle ground worth naming. The class of tools that sit between a spreadsheet and a full labeling platform. Lightweight web annotators, spreadsheet-plus-image workflows, structured forms. If the task is classification-plus-fields rather than dense detection, you can do it in Airtable or Google Sheets with image URLs. You photograph the part, the photo syncs to a folder, you open a form, you type six fields, you hit next.
There are also a handful of open-source tools that are lightweight — single-file web apps that let you load a folder of images and type labels into a form. They don't have the review queues or the team management, but for one person and a hundred images, that's a feature, not a bug.
And on Android specifically, the most practical workflow might be no annotation tool at all. Shoot the photos in a consistent setup, then do the annotation on whatever screen is most comfortable. The phone is the capture device, not the labeling device. Trying to type structured fields on a phone keyboard for a hundred images is a recipe for typos in the training data.
Typos in the training data become typos in the model output.
And Daniel cares about the title format. A typo in the title field is exactly the kind of error that propagates.
So the tooling answer is: the annotation tool choice is downstream of the schema choice. Get the schema right — fixed fields, a template for the title, length as a first-class field — and the tooling question mostly answers itself. A form with an image attached, or a spreadsheet with thumbnails. Not Label Studio.
Which is the misconception worth naming directly. You don't need a full labeling platform for a hundred-image dataset. The instinct to reach for the professional tool is strong, but the professional tool is built for a different problem. It's built for coordinating teams and managing versioned datasets and running quality control on a million annotations. Daniel's problem is one person, one afternoon, one drawer.
Okay. You've got your hundred images and your schema. Now: what do you train?
Two paths. Path A is fine-tuning a large vision-language model to emit structured output. Path B is training a small, task-specific model — a classifier plus a regression head, or a small vision encoder with a structured decoder.
Let's steelman the large VLM first, because it's the path that looks attractive on the surface. Structured output is exactly what these models are getting good at. You can show them an image and ask for a JSON object with specific fields, and they'll do it. Fine-tuning on a hundred examples is now feasible with parameter-efficient methods — you're not retraining the whole model, you're training a small adapter.
And the advantage is you skip the architecture work. You don't have to design a model head or think about output vocabularies. You just format your training examples as image-plus-JSON pairs and let the model learn the mapping. The language-level flexibility means it can handle novel titles or descriptions that weren't in the training set.
The downside is that you're paying for the whole visual world when you only need a drawer. A large VLM spends capacity on recognizing cats and cars and street signs and a million other things. For a hundred images of hardware parts with a fixed schema, that's waste. It's also expensive to run, and if Daniel wants this thing to work offline in his workshop, a large VLM is the wrong shape.
The small model case is strong on this task. A hundred images, one domain, a fixed schema, and a need to run cheaply and locally. A small model trained on a hundred well-annotated images can beat a general VLM at this narrow task, because it doesn't have to spend capacity on the rest of the visual world. It can specialize.
And the closed vocabulary is the deciding factor. If Daniel's drawer has sixty-four known part types, and the schema is fixed, then the model doesn't need to generalize to unseen part types. It needs to map an image to one of sixty-four categories, plus a length estimate. That's a classification problem with a regression head. A small model is the natural fit.
The open-vocabulary case is where the large VLM earns its keep. If a new part arrives that isn't in the catalog — a weird standoff or a specialty fastener — the small model will confidently misclassify it as whatever it looks most like. The large VLM has a better chance of saying something sensible, because it's seen more of the world.
So the answer to fine-tune-large versus train-small depends on whether the vocabulary is closed or open. For the sixty-four-part box, closed. Small model wins. For a general hardware-identification tool that has to handle anything that might show up, the large VLM's generalization is worth the cost.
But there's a hybrid that I think is the practical answer for Daniel's fifteen-minute capture session. Use a large VLM to bootstrap labels for the small model. Daniel annotates a hundred images by hand. He runs a large VLM over the same images to generate candidate structured records. He corrects the VLM's mistakes. Now he has a corrected set, and that corrected set trains the small model. The small model learns from the corrections, not from the raw VLM output.
That's a nice division of labor.
The knock-on effect is where it gets interesting. Once the small model exists, the inventory system changes. The model becomes the labeling interface. You photograph a new part, the model proposes a record, you confirm or correct. The dataset grows as a byproduct of using the inventory. Every correction is a new training example.
The drawer becomes the dataset, and the dataset becomes the inventory.
That's the loop. And it's why getting the schema right up front matters so much. If the schema is wrong, every correction is fighting the schema. If it's right, the corrections are just data.
Now the length-deduction question, because that's the part Daniel flagged as ideal and I think it's the part most likely to fail with a hundred images. He wants the model to deduce length without him providing it. That's a metric-estimation problem from a single image, and perspective distortion is exactly what breaks it.
The honest answer is that length from a single phone photograph without a reference object or a fixed camera rig is not reliably solvable. Not with a hundred images, not with a thousand. The information isn't in the pixels. You can't recover absolute scale from a single image of an unfamiliar object. You need either a known reference in frame or a calibrated camera setup.
Daniel already has the reference object. The scale ruler. If every training photo includes the ruler, the model can learn to read the ruler. That's not deducing length without being told — it's deducing length from a visible scale, which is a much more tractable problem.
It's also a different annotation decision. If the ruler is in frame, the length field is something the model can learn to read. If the ruler isn't in frame, the length field is something the model has to memorize per part type. And memorized length only works for parts it's seen before. A new part with a new length fails.
The length-deduction goal, as stated, is probably the wrong goal. The right goal is length-from-visible-scale, which is achievable with the workflow he already has. The fifteen-minute capture session is the easy part. The schema and the length problem are where the real work is.
The perspective distortion gotcha ties directly into this. Identical parts photographed at different angles and distances produce different apparent lengths. If the training images vary in angle and distance, the model learns the camera setup, not the part. So the capture protocol has to control for that. Same distance, same angle, same ruler position. Every time.
That's a discipline thing, not a tooling thing. It's the kind of thing that's easy to say and hard to do consistently over a hundred photos.
It's also the kind of thing where a simple jig helps. A fixed phone mount, a fixed background, a marked spot for the ruler. Fifteen minutes of setup saves you a hundred photos of inconsistent framing.
Let's pull the two halves together. The data half: consistent capture, a fixed reference object, a schema that separates predicted fields from given fields, and a tooling answer that's probably a form with an image attached rather than a labeling platform. The model half: for a closed vocabulary and fixed schema, train a small model. Use a large VLM to bootstrap labels if you want. Don't expect length deduction without a visible scale.
The misconception worth naming on the model side is that a large vision model is automatically the right choice because the output is structured. Structured output is not the same as needing a large model. A small model can emit structured output perfectly well if the schema is fixed and the vocabulary is closed. The large model earns its keep when the vocabulary is open and the output has to vary.
The other misconception is that annotation tooling for phones is a solved problem. It isn't. The lightweight, phone-native options are thin, and most mobile tools are thin clients for a desktop or cloud backend. The phone is a great capture device and a mediocre labeling device.
That's fine. The workflow should match the tool to the job. Capture on the phone, annotate on whatever screen is comfortable, train a small model, and let the model become the labeling interface for everything that comes after.
There's a version of this that's just about screws, and a version that's a template for everything else.
Hilbert: You keep saying length is the hard variable. It isn't. Thread pitch is the hard variable. Two screws, same length, same diameter, completely non-interchangeable because one's a coarse thread and one's a fine thread. No phone photograph is going to resolve thread pitch reliably. Not at the resolution you get from a hundred casual photos.
That's a fair correction. Thread pitch is invisible at most phone-photo scales, and it's exactly the kind of detail that determines whether a screw fits or strips the hole.
Hilbert: I spent two years at the parts counter of a farm-equipment dealership in central Illinois. Late eighties. The entire job was identifying small hardware from a drawer by eye. And the thing you learned fast was that length was the easy variable. You could eyeball length. You could not eyeball thread pitch. You kept a thread gauge on the counter and you used it on anything that mattered.
Daniel's length-deduction goal might be solving the easy problem while the hard one sits there unaddressed.
Hilbert: That's what I'm saying. I lost three hundred forty dollars in 1994 on a mail-order lot of assorted self-tapping screws that turned out to be ninety percent one size I already had. That's the original inventory problem. You don't know what you have, so you buy what you think you need, and you end up with more of what you already had.
The thread-pitch point actually changes the schema discussion. If thread pitch is a field the model can't see, then it has to be a field the model memorizes per part type. Which works for the closed set of sixty-four known parts, but breaks the moment a new part shows up.
Hilbert: That's the thing. The drawer dividers I bought in 1991, the plastic bins, I still use them. Moved them across four states. They're better than anything you can buy now. But the bins don't tell you the thread pitch either. You still have to check.
Would you photograph the dividers for the dataset?
Hilbert: No.
Hilbert: The point isn't the dividers. The point is that the model's going to learn what you teach it, and if you teach it length and category and title, it's going to be very confident about length and category and title. And it's going to be wrong about the thing that actually matters when you're standing in the workshop holding two screws that look the same.
That's the second-order risk. A model that's confidently wrong about thread pitch is worse than no model, because you'll trust it.
Hilbert: I wouldn't trust it. But somebody would.
The schema needs a field for the things the model can't see, and a workflow for filling those fields by other means. The thread gauge doesn't go away. It becomes part of the annotation process.
That's actually a clean resolution. The model handles what's visible — category, approximate length with a scale reference, title template. The human handles what's not visible — thread pitch, material, anything that requires a gauge or a magnet or a closer look. The model proposes, the human disposes.
Hilbert: That's what the parts counter was. You looked at the part, you made a guess, you checked the gauge. The gauge was never optional.
The fifteen-minute capture session might need a sixteenth minute with a thread gauge.
Hilbert: Or a tenth of a second per part if you're organized. Which is the whole point of the drawer.
The interesting thing about this episode is that the hardware model is almost a distraction. The template is what matters. Any domain where you can gather a hundred consistent photos in fifteen minutes is a candidate for a tiny structured-output model. The drawer is just the first instance.
The open question is what the personal-scale training workflow looks like in a year. The tools are built for teams. The mismatch is real. But the pattern — capture on a phone, annotate in a form, train a small model, let the model become the interface — that pattern doesn't need a team. It needs one person with a drawer.
The cutting-room floor detail I keep thinking about is that the scale-ruler workflow Daniel already uses is doing something the training task can't easily replicate. When he photographs a part next to a ruler and asks an agent what it is, the agent is reading the ruler. It's a visual reasoning task. A small trained model could learn to read a ruler too, but only if the ruler is in the same place in every training image. The generalization is the hard part.
The forward-looking thought is this. The drawer is the dataset, and the dataset is the inventory. Once the model exists, every new part that goes in the drawer becomes a training example. The inventory improves itself. That's the version of this that's a template for everything else.
Thanks to Hilbert Flumingtop for producing.
This has been My Weird Prompts, the human-AI collaboration podcast.
If you enjoyed this, leave us a review wherever you listen.
We'll be back soon.
