Compare food-scanning apps with the same packages and explicit error counts
Design a small reproducible evaluation that reports tasks, denominators and uncertainty without inventing a universal winner.
To compare food-scanning apps fairly, give them the same tasks on the same packages and define success before viewing the results. A few appealing screenshots do not establish accuracy, and a test of one feature does not evaluate every feature an app offers.
Choose a narrow task
Start with something observable, such as extracting serving weight and a named nutrient amount from a readable label. Create a reference transcription from the package and verify it independently before testing. The FDA label-reading guide can support interpretation of the fields; it does not certify your test or any app.
Record each package's identity and source image. Choose a varied but manageable set, and describe its limits: for example, only English-language dry-food packages photographed in good light. Do not describe that sample as representative of every shopping situation.
Use the same procedure
Record app version, device, date, input image and relevant settings. Decide in advance whether retries and manual corrections are allowed. If you test a barcode workflow in one app and image transcription in another, report those as different tasks rather than claiming a direct accuracy contest.
Save raw outputs before correcting anything. Track identity mismatches, amount errors, unit errors, missing fields and unreadable-reference cases separately. A wrong product match should not be counted as successful extraction merely because the displayed numbers look plausible.
Report denominators honestly
In a hypothetical test of 12 packages with four scored fields each, there are 48 planned field checks. If two reference fields are unreadable, report 46 assessable checks and two excluded checks with reasons. If 42 of the 46 assessable outputs match, state 42/46 rather than converting the result into a broad claim that the app is accurate in all conditions.
Also report package-level completion. Several field errors concentrated in one package tell a different story from one error in each of several packages. Time to finish can be useful, but distinguish automatic processing time from time spent checking and repairing results.
Publish the procedure, sample limits and observed counts together if you share the evaluation. Avoid choosing new exclusions after seeing which app they favor. No real app performance is reported in this example; it is a method for collecting evidence before forming a recommendation.