How accurate is calorie counting from a photo?

Photographing a plate and receiving a calorie count is an appealing idea, and the part of it that works is not the part that matters.

What works: identification

Recognising that a plate contains rice, dal, a sabzi and two rotis is largely a solved problem. Image models do this well, including for regional dishes, and it removes the slowest step in logging — finding the right database entry.

That alone has value. A photo that pre-fills four food entries and asks you to confirm quantities is meaningfully faster than four searches.

What does not work: quantity

A single photograph does not carry depth, density or weight.

How deep is the bowl of dal? How tightly is the rice packed? Is that roti 35 g or 55 g? These are the questions that determine the calorie count, and a two-dimensional image answers none of them reliably.

Reference objects and depth sensing help. They do not solve it, particularly for anything served in a bowl.

What is invisible: the fat

This is the fundamental limit for Indian food.

A dal made with one teaspoon of oil and one made with four tablespoons look nearly identical in a photograph. They differ by about 90 kcal per katori, which is the difference between a dish that fits your target and one that does not.

The same applies to every gravy, every sabzi and every fried item, where the absorbed oil is both the largest variable and completely invisible. That is the whole argument of how much oil is actually in your curry, and no camera resolves it.

Where the errors land

Best case: a simple plate of separated, recognisable foods with a reference object for scale. Grilled chicken, rice, a salad. An estimate within perhaps 20 per cent.

Middling: a standard thali, where portions are conventional and the app has seen thousands like it.

Worst case: mixed dishes, curries, biryani, anything fried, anything where the recipe is unknowable. Errors of 40 per cent or more in either direction.

The pattern is the same as everywhere else in food tracking: accuracy falls as you move away from ingredients you handled yourself, per how accurate are calorie counts, really.

The right way to use it

As a memory aid. A photograph taken at the moment of eating is a reliable record of what was on the plate. Logging from a photograph in the evening is far more accurate than logging from memory, which reliably drops the bread, the second helping and the two bites.

As a starting point. Let it identify the foods, then correct the quantities yourself using your own calibrated servings — how to track calories without a food scale.

As a check. Comparing what you photographed with what you logged, once a week, finds portion drift quickly.

The wrong way to use it

Accepting the number. An estimate presented to three significant figures invites a confidence the method does not support, and a log built on uncorrected photo estimates will be wrong by a variable amount — which is worse than being wrong by a consistent one, for the reasons in why two apps give the same roti different calories.

Compared with the alternatives

Versus barcode scanning: photos cover far more of a typical diet and are less accurate per item — what barcode scanning can and cannot do.

Versus typing or speaking what you ate: faster to capture and slower to correct. A person who says "two roti, dal, katori curd" has given more usable information than a photograph of the same plate, because they know their own portions — logging food by voice: what it actually fixes.

Versus a saved recipe: no contest. A dish you calculated once and saved is accurate and takes one tap.

Where it is heading

The identification will keep improving. Quantity estimation will improve with better depth sensing. The fat content of a home-cooked dish will remain unknowable from an image, because the information is not in the image.

That is a hard limit rather than a temporary one, and it is worth keeping in mind when a product claims to have solved calorie counting with a camera.