Why photo calorie estimates run low, and what to do about it
If you have used any AI calorie app for a week, you have probably had the same suspicion: the numbers feel a bit low. That suspicion is usually correct, and the reason is not that the model is bad at recognising food. It is that calories are mostly invisible in a photograph.
The bias is structural, not random
A random error would be fine. Over a week of logging it would cancel out and your weekly average would still be usable. Photo estimation does not behave that way, because the things a camera cannot see are systematically the calorie-dense ones.
Fat leaves no trace. A tablespoon of olive oil is about 120 kcal. Once it is absorbed into a pan of vegetables it is completely undetectable in an image. The same visible plate of roasted vegetables might be 180 kcal or 420 kcal, and the photograph is identical either way.
Depth is a guess. A camera sees the top surface of a bowl of rice. It does not see how deep the bowl is or how tightly the rice was packed. Both of those change the answer by a lot, and neither is visible.
Things sit under other things. Curry over rice. Dressing under leaves. Cheese melted into a sauce. Anything a model has to infer, it infers conservatively, and conservative means low.
Scale needs a reference. Without a known object in frame, a dinner plate could be 22cm or 28cm. That is a 60% difference in volume for an identical-looking photo.
Every one of those failure modes pushes the estimate the same direction: down.
What actually helps
Shoot from about 45 degrees. Directly overhead throws away all depth information. Side-on hides the back half of the plate. Around 45 degrees gives the model both the surface area and some sense of height.
Put something known in the frame. A fork, a standard mug, your hand at the edge of the plate. Any object with a known size gives the estimate a scale anchor, and scale is one of the biggest sources of error.
Correct the portion, every time it looks off. This is the part people skip, and it is the part that matters most. You know you used three tablespoons of oil. The camera does not and never will. A two-tap correction is not a failure of the app; it is the app working as intended.
Use exact figures wherever they exist. Anything with a barcode has a manufacturer's published number on it. Anything with a printed nutrition panel has the figures right there. Neither of those needs estimating, and reading them is faster than photographing them anyway. In KalTrack both are free and unlimited, deliberately.
Add a mental margin on restaurant food. Restaurant kitchens use more fat than home kitchens, consistently. If a restaurant plate comes back at 600 kcal, treating it as 700 is closer to right than treating it as 600.
Consistency beats precision
Here is the part that makes all of this workable. If you log the same way every day, a systematic bias mostly cancels out of the comparison that actually matters.
Say your method reads 15% low. Every day. Your logged 2,000 kcal is really 2,300. That sounds bad, and it would be bad if you were trying to hit an absolute target. But you are almost certainly not — you are trying to answer "am I eating more or less than last week, and is my weight moving the way I want?" A consistent 15% bias barely affects that question. An inconsistent method — careful on Monday, guessed on Friday, skipped on Saturday — wrecks it completely.
So the goal is not a perfect number. It is a method you will still be using in six weeks, applied the same way each time, with the exact figures used wherever they are available.
That is the whole design argument behind KalTrack: a fast estimate you will actually record, presented honestly enough that you know when to correct it.