Emira

Ways to log a meal

Five ways in. Each precise about something different.

Trackers usually pick one input and build everything around it. Emira takes five, because the meals people actually eat do not all give you the same information. This page is the practical comparison: what each method gets right, where each one breaks, and which to reach for.

The comparison

Strengths and weaknesses below are failure modes we have observed across benchmark runs and everyday use, described as behaviour rather than scored as percentages.

Text

You write what you ate, the way you would tell a person: “180 g chicken breast, rice, a spoon of olive oil”.

Reliable at
Amounts. If you state a quantity, it is used as given rather than guessed at, and that removes the single largest source of error.
Weak at
Product identity. “Yoghurt” could be 45 kcal or 130 kcal per 100 g, and nothing in the sentence says which one you had.
Speed
A few seconds to type, roughly a second to analyse.
Best for
Home cooking and anything where you know the amounts but there is no package to scan.

Barcode

You scan the package and the exact product is identified from its catalogue entry.

Reliable at
Product identity and nutrition density. The values come from the product record, not from an estimate.
Weak at
How much of it you actually ate. A scan says what the product is, never whether you had half the pack or all of it.
Speed
Effectively instant. The catalogue lookup takes well under a millisecond.
Best for
Packaged food, drinks, protein bars, anything with a label.

Photo

You take a picture of the plate and Emira works out what is on it.

Reliable at
Composition. A photo shows the side salad, the sauce and the oil sheen that people leave out when they type.
Weak at
Portion size. Across our benchmark runs the dominant error was never retrieval. It was portions and servings, and a flat image is exactly where that judgement is hardest.
Speed
About a second of analysis after the shot.
Best for
Restaurant plates and mixed dishes you could not itemise if you tried.

Voice

You say the meal out loud and it is handled like text.

Reliable at
The same strengths as text: stated amounts survive.
Weak at
The same blind spot as text, plus whatever the transcription mishears in a noisy kitchen.
Speed
Fastest way in while your hands are busy.
Best for
Cooking, driving, or any moment where typing would mean not logging at all.

Recipe link

You paste a URL and the page is read before anything is logged.

Reliable at
Ingredient lists. Where a page carries a nutrition table, the model recovers it far more completely than pattern matching does.
Weak at
Your share of it. A recipe is for four people; how much of it ended up on your plate still has to come from you.
Speed
Around 1.4 s to read the page, once.
Best for
Meals cooked from a recipe, and anything you will make again.

Why the mix wins

Each method is precise about something different and blind to something else. Barcode fixes the product but not the portion. Text fixes the portion but not the product. A photo sees the whole plate but judges quantity worst of all. Combining them is not a gimmick. It is the only way each blind spot is covered by something that can actually see it.

What to use, by situation.

If you only remember one thing from this page: name or scan the product, then say how much. Those are the two facts that decide the total.

Measured speed

Medians from our own runs. Each figure names the run it came from.

Product catalogue lookup

0.26 ms

Median over 100 German-language product queries against a 10,004-row catalogue; the 95th percentile is 0.29 ms. This is the step behind a barcode scan, which is why scanning feels instant.

benchmark/LOCAL_CATALOG_RETRIEVAL_BENCHMARK.md · measured 2026-07-12

Photo and text analysis

1.17 s

Median model latency across 19 real meal photos with an accompanying sentence. The slowest case took 3.37 s. A second, cheaper model was roughly 2.6x slower at 3.06 s median.

benchmark/vision_comparison/results/2026-07-31 · measured 2026-07-31

Recipe and web page extraction

1.40 s

Median across 8 nutrition pages, from 0.73 s to 6.04 s. This is the step that runs when you paste a recipe link and the page has to be read before anything can be logged.

benchmark/out/web_nutrition_extractor_benchmark.json · measured 2026-07-31

Coming soon

Measured accuracy per method

We can tell you how long each method takes because we have measured it. We are not going to tell you how accurate each one is until we have measured that too. The existing vision runs record latency and cost but carry no ground truth, so any accuracy figure per method would be a number we made up.

The run that would settle it sends one test set through every input method against a known reference. When it exists, its results appear here and on the accuracy page.

Questions people ask

Which logging method is the most accurate?
There is no single answer, because they fail differently. A barcode is exact about the product and silent about the amount. A typed sentence is exact about the amount and vague about the product. The most accurate entry is usually a combination: scan or name the product, then state how much.What we have and have not measured
Why not just use photos for everything?
A photo is very good at seeing what is on a plate and poor at judging how much of it there is. Across our benchmark runs, portion and serving errors were the dominant failure, and a flat image is the hardest place to judge mass.What the restaurant research shows
Do I have to choose one method?
No. A single entry can combine them: scan the yoghurt, photograph the bowl, and say how much granola went in. They all feed the same result.How the inputs are combined
How long does each method take?
The catalogue lookup behind a barcode takes well under a millisecond. A photo takes about 1.2 seconds to analyse. A recipe link takes about 1.4 seconds to read, once. Typing is bounded by how fast you type, not by the analysis.Where the time goes