Teaching a tiny model to find a pet’s face

A customer chooses a favourite photograph of their pet. The Pet Analysis Studio finds the animal, locates its head and prepares a circular avatar. There is still room to adjust the result, but the customer starts with something considered instead of an arbitrary square.

That small interaction became an interesting engineering problem. A whole-animal detector could tell me where the dog or cat was. It could not tell me how to frame its face. “Use the upper part of the animal” was a useful fallback, but body shape, pose and framing made it a weak default.

I needed a much narrower capability: find the pet’s head and return useful geometry. The result was a custom detector of about 3.5 MiB, built to run on CPU. Its validation result was strong. Understanding what that result could support was just as important as achieving it.

Give the model one useful job

Pet Analysis Studio grew out of my work on Pet Manager’s customer experience. I wanted adding a pet to feel more personal and require less manual setup. A photograph could become a starting point for profile suggestions, an avatar and a caption, with each result editable.

I separated the work into components. Whole-animal detection finds the subject. Classification suggests a species or breed. The head detector supplies crop geometry. Caption generation has its own contract. This makes the components easier to inspect and replace, and lets the experience survive when one of them has no useful answer.

The head detector predicts one class, pet_head, shared by dogs and cats. It does not recognise an individual animal, identify facial landmarks or establish pedigree. That boundary keeps both the implementation and the product promise understandable.

Detection versus classification

Classification answers “what is in this image?” Detection adds “where is it?” A label such as “dog” cannot tell the interface where to position a circular frame. A bounding box supplies the location and dimensions needed to construct one.

For this feature, the useful output is a rectangle. Recognising more categories would not, by itself, make that rectangle better.

Keep the model small and the experiment repeatable

I chose YOLOX Nano and initialised it from the official COCO checkpoint. Compatible pretrained weights supplied a starting point; the original classification prediction layers did not fit the new single-class output and were left to learn the task.

The head annotations in the Oxford-IIIT Pet dataset supplied 3,687 boxes across 3,686 usable annotated images. I converted them into the format required by the training pipeline and made a deterministic, breed-stratified split: 2,948 training images and 738 validation images.

Repeatability matters when comparing experiments. Rebuilding the dataset should not quietly produce a different holdout that makes the next model look better. Stratification also helps keep breeds represented on both sides of the split. Neither property makes the holdout independent of Oxford’s photographic and annotation characteristics.

The run used 416 × 416 inputs over 60 epochs. Geometric and colour augmentation introduced variation in pose, scale and lighting. The experiment stayed deliberately bounded, with its configuration and effective run behaviour retained for inspection.

The retained training setup

Setting	This experiment
Architecture	YOLOX Nano, one pet_head class
Logged size	0.90M parameters, 1.08 GFLOPs
Input / test size	416 × 416
Training	60 epochs, batch 32, one GPU, FP16
Random seed	42
Optimiser	Nesterov SGD, momentum 0.9
Learning rate	0.005 at batch size 32
Schedule	Warm cosine with 2 warm-up epochs
Multi-scale inputs	320–512 pixels in steps of 32
Mosaic	Probability 0.5, disabled near the end
MixUp	Disabled

The dataset split uses the fixed string seed pet-manager-head-v1. It validates dimensions, species metadata and box geometry, and converts one-based inclusive VOC coordinates into zero-based COCO boxes.

The configuration sets no_aug_epochs=10; the retained log shows mosaic switching off and L1 regression switching on at displayed epoch 50. The log is the evidence for what actually happened.

The composite training objective combines weighted IoU loss, objectness and classification loss, with L1 box regression added in the closing stage. These are components of an optimisation objective, rather than four interchangeable quality scores.

Evaluate the artifact that will run

Training produced a PyTorch checkpoint. I exported the selected checkpoint to ONNX opset 13 so the service could use ONNX Runtime on CPU without carrying the training framework or a GPU dependency.

The exported file is 3,652,051 bytes—about 3.5 MiB. The build retains a checksum so the model can be identified precisely. I then evaluated that exported artifact on all 738 validation images, closing the gap between a training result and the representation the service actually loads.

Why export to ONNX?

ONNX is a format for representing trained models. ONNX Runtime executes those models across supported platforms. Here, that separates the GPU-based training environment from a smaller CPU-based service.

Successful export is not proof that behaviour is unchanged. Preprocessing, numerical differences and output interpretation still need to be checked. That is why the exported model gets its own evaluation.

The retained validation report records:

Measure	Exported ONNX result
AP50	0.9904
Precision at IoU 0.50	0.9905
Recall at IoU 0.50	0.9905
Mean best IoU	0.8983
Median CPU inference, Runpod host	195.88 ms

These results describe the 738-image Oxford holdout. The latency describes the recorded Runpod CPU evaluation environment; it is not an Azure production latency promise or an end-to-end onboarding time.

What does AP50 actually tell us?

Intersection over union, or IoU, measures the overlap between a predicted box and an annotated box, divided by the area they cover together. An IoU of 1 means perfect overlap.

Precision asks how many predicted detections match annotations. Recall asks how many annotated heads were found. AP50 summarises the precision–recall relationship with a match defined at IoU 0.50.

That is a specific detection measure, not a universal “99% accurate” score. It cannot tell us whether the crop looks good inside a circle or whether someone will accept it without adjustment.

Exported-model evaluation conditions

The validator used ONNX Runtime’s CPU execution provider, a score threshold of 0.20, non-maximum suppression at 0.45, and matching IoU at 0.50.

The retained report records median / p95 / maximum inference of 195.88 / 211.22 / 298.72 ms and model load time of 77.51 ms. These measurements belong to that host and run.

Separately, the trainer’s final COCO evaluation recorded AP50:95 of 0.835 and AP75 of 0.934. Those checkpoint metrics use stricter overlap criteria and should not be conflated with the standalone ONNX report.

The service also owns preprocessing, output decoding, score handling and coordinate clipping. These transformations form part of the deployed behaviour; an ONNX file alone does not define the complete inference contract.

Know where the evidence stops

The validation images were withheld from training, but they came from the same dataset. The result supports a claim that the exported model learned Oxford’s dog-and-cat head-box task well.

Customer photographs introduce different conditions: a distant animal, motion blur, severe occlusion, awkward framing or overlapping pets. A representative evaluation of those conditions is a separate piece of work. A strong in-domain score makes the next evaluation worthwhile; it cannot replace it.

There is a second boundary: detector quality and avatar quality need different evaluations. A box can meet an overlap threshold while leaving an ear too close to the circular frame. A crop may look good despite differing from the annotation.

Before making claims about customer-photo performance or automatic crop acceptance, I need representative images and a structured review of usability. I also have no measured basis here for claiming better conversion, retention or onboarding completion. Those would require product evidence.

Make uncertainty part of the experience

After detection, the pipeline translates the head box into the original photograph’s coordinates. The crop service creates a square with a default total margin of 27.5%, with slightly more room below the head’s centre than above it.

The Studio lets the person adjust that framing without rerunning inference. The model supplies a useful starting point; the person retains the final decision.

When no credible head is returned, the service uses an upper-animal crop and explicitly labels it heuristic-upper-animal. It also returns a warning. An editable fallback keeps the workflow moving without claiming that the model found something it did not.

Those details connect model engineering to interface design. The API communicates where a result came from. The geometry anticipates the circular mask. The interface makes correction inexpensive. They are all parts of the same feature.

The useful result is the connection

This project started with a modest product need and ended with a narrow model, reproducible data preparation, an evaluated CPU artifact and a considered path through uncertainty.

The lesson I take forward is to define the action a model’s output will enable before expanding its ambition. Four coordinates can be enough—provided the software around them knows how to turn them into something useful.

That is what I mean by building intelligent experiences: connecting AI, engineering and product judgement closely enough that the person using the product has less work to do.

Sources and scope

Project figures come from the retained Pet Analysis Studio dataset manifest, training log, ONNX validation report and implementation. They describe this experiment; they are not independent third-party benchmarks.

• Oxford-IIIT Pet dataset: source of the dataset and head annotations. Oxford identifies the dataset as CC BY-SA 4.0, with image copyright retained by the original owners. No dataset photographs or model weights are distributed with this article.
• YOLOX paper and pinned implementation: architecture and training implementation.
• ONNX Runtime documentation: runtime background.

The cover is an AI-generated editorial illustration. It is not a model prediction, customer photograph or validation example.