iLog 2.2: Volume and Nutrition Estimation for Mixed Foods via Mask R-CNN and Federated Learning

Abstract

Accurately estimating calorie intake and nutrient composition from what we eat remains one of the most practical challenges in maintaining a healthy lifestyle. Manual food logging and database-based estimations are often inaccurate because ingredient proportions and preparation styles vary widely. This paper presents a lightweight, privacy-preserving framework that estimates calories and detailed nutrient values from a single image. The model uses a Mask R-CNN-based segmentation network to identify visible food components, measure their area, estimate their volume using preset height values, and map them to nutritional information obtained from reliable datasets such as USDA and Food-a-pedia. The system integrates federated learning (FL) to ensure privacy by allowing the model to improve collaboratively without sharing raw user data. The proposed architecture achieved a mean Average Precision (mAP) of 96% for detection and 92% for segmentation, confirming its precision and efficiency. The model is trained and evaluated on a curated pizza dataset consisting of 1107 images across 50 topping categories, using a standard train-validation-test split (666/219/222) to ensure reliable performance assessment. The proposed system also achieves low nutrition estimation error, with calorie and nutrient deviations remaining within approximately 3.8% to 11.1% across evaluated metrics. A lightweight mobile interface is demonstrated through a Figma-based prototype mockup to illustrate potential real-world deployment and user interaction.

1. Introduction

The healthcare and nutrition industries are increasingly shaped by technological innovations that aim to quantify dietary patterns and energy intake. Accurate estimation of calorie and nutrient composition plays a vital role in weight management, chronic disease prevention, and personalized healthcare [1]. However, in real-world scenarios, this process is not straightforward [2]. People consume meals that often combine multiple ingredients, with varying portion sizes and preparation styles. Mixed dishes, such as sandwiches, bowls, and layered meals, make calorie estimation particularly challenging since the same type of meal can differ greatly depending on regional recipes, ingredient density, and cooking variations.

These differences make it difficult for individuals to rely on general or pre-defined calorie charts, as such values represent only average estimates and do not account for user-specific variations. As a result, most people and healthcare professionals depend on manual food logging or rough estimation, which can be time-consuming and inaccurate [3]. Figure 1 illustrates a person struggling to manually calculate calories and nutrient composition from a mixed meal, highlighting the complexity and need for an automated approach.

To address this challenge, iLog 2.2 focuses on precise and automated calorie and nutrient estimation using artificial intelligence (AI) and edge computing. Unlike the earlier [4], iLog 2.0 [5] & iLog 2.1 [6], which handled multiple food categories and provided broader calorie predictions through object detection, this version enhances the overall accuracy and nutrient breakdown by modeling individual components in greater detail. The system applies geometric and visual analysis to estimate volume and mass directly from 2D images without requiring depth sensors or additional hardware. This refined approach not only predicts total calories but also estimates macro-nutrient and micro-nutrient composition, offering detailed insights into protein, fat, carbohydrates, sodium, calcium, and other essential nutrients.

A major contribution of this work is the integration of federated learning (FL) for privacy-preserving training and continuous model improvement [7]. In conventional AI-based food analysis systems, user data, such as food images are sent to centralized cloud servers, raising privacy and ethical concerns. In contrast, iLog 2.2 performs computation locally on the user’s device. Each device trains the model on its private dataset and shares only encrypted model parameters—not raw images—with a central server for aggregation. This ensures that user data remains private, aligning with modern data protection standards, such as the General Data Protection Regulation (GDPR) and Health Insurance Portability and Accountability Act of 1996 (HIPAA) [8,9]. The federated architecture allows the model to learn from diverse user inputs while maintaining strong privacy guarantees.

Another core design goal of iLog 2.2 is efficiency and deployability. The system employs a lightweight deep learning model suitable for smartphones, embedded platforms, and Internet-of-Medical-Things (IoMT) devices, following the principles demonstrated in recent IoMT-based smart health systems [10]. This enables real-time inference with low latency and minimal computational overhead, making it practical for daily use. The modular nature of the framework also allows integration with mobile health applications, enabling users to share only summarized nutrient values with dieticians or healthcare professionals. Instead of exposing raw images or personal information, the system communicates aggregated nutritional summaries, maintaining both privacy and interpretability. Despite the progress in food recognition and calorie estimation systems, several challenges still remain in practical applications. Many existing approaches focus mainly on food classification or segmentation but do not accurately estimate portion size or volume, which limits their usefulness for real dietary tracking. In addition, most systems treat food as a single entity and do not consider ingredient-level variations, which becomes a major issue for mixed dishes like pizza where each component contributes differently to the final nutritional value. Another limitation is that conventional systems depend on centralized processing, where user data is sent to cloud servers, raising concerns about privacy and scalability.

Motivated by these challenges, this work focuses on building a lightweight and privacy-preserving system that performs ingredient-level analysis, estimates volume and mass directly from a single image, and computes detailed macro- and micro-nutrient values. The main hypothesis of this work is that combining instance segmentation with geometric estimation and federated learning can provide accurate, interpretable, and privacy-aware nutrition estimation for mixed food items in real-world conditions.

By combining computer vision, federated learning, and AI-driven automation, iLog 2.2 eliminates the guesswork involved in calorie and nutrient estimation. The framework demonstrates how a focused and structured approach to analyzing mixed or multi-component meals can serve as a proof of concept for future large-scale food estimation systems. In doing so, it bridges the gap between nutrition science, privacy-preserving AI, and practical usability. This research contributes to the broader goal of personalized healthcare through intelligent dietary monitoring, where individuals receive accurate, secure, and adaptive feedback on their nutritional intake without compromising privacy. Figure 2 illustrates a user effortlessly obtaining detailed nutritional information through the proposed application.

2. Related Work

The comparison presented in

Table 1. Comparison of Research Works in Food Vision, Portion/Volume, and Nutrition Estimation.

Title	Dataset/Input	Core Method	Vol. Est.	Nutrition Granularity	Federated Learning/Edge Compatibility	Key Insights
iLog (Rachakonda et al.) [4]	Mixed/food images + sensing (IoMT)	Detector + intake monitoring + stress detection (IoMT device)	No	Per-intake/monitoring oriented (not detailed nutrients)	No	Focuses on automatic intake monitoring + stress detection; not a full nutrient pipeline.
iLog 2.0 (Mitra et al.) [5]	Multi-class food images	Food detection + nutrition quantification	No	Per-dish (general)	No	Limited volumetric/geometry-driven accuracy.
iLog 3.0 (Siripurapu et al.) [17]	2D RGB food images	Mask R-CNN + monocular depth (MiDaS-style) for volume inference	Yes	Per-dish (derived)	No	Accurate volume from 2D + depth; higher compute than pure detection.
Mask R-CNN Volume + Calories (Dai et al.) [18]	RGB images (solid foods; example-based)	Mask R-CNN instance segmentation + calibration-based calorie estimation	Approx. (via calibration)	Global calories (per item/dish)	No	Strong masks; needs calibration/assumptions; shows extension to multiple solid foods.
SEG-FOOD Dataset/Segmentation (Tahir & Kiong) [12]	Food segmentation dataset (semantic masks)	Deep learning semantic segmentation (dataset + baseline models)	No	N/A	No	Useful benchmark dataset for segmentation; no portion/nutrient computation.
Lightweight DeepLabv3+ (Muñoz et al.) [13]	Multiple food segmentation datasets + self-collected set	EfficientNet-B1 backbone + CWASPP + SE attention (semantic seg.)	No	Region-level only	Edge-friendly (lightweight)	High segmentation performance with reduced compute; does not estimate calories/volume.
mid-DeepLabv3+ + CamerFood10 (Erep et al.) [19]	African food dataset (CamerFood10)	Enhanced DeepLabv3+ (ResNet50 + SimAM) for semantic seg.	No	Region-level only	No (not FL)	Improves segmentation on underrepresented cuisines; still no nutrient pipeline.
FDSNet (Xiao et al.) [20]	FoodSeg103/UECFoodPixComplete	Dual-branch (Swin Transformer + CNN) multi-scale fusion segmentation	No	Region-level only	No	Better accuracy/efficiency for large images; segmentation-focused.
Two-View 3D Reconstruction (Dehais et al.) [21]	Multi-view images (two views)	Two-view 3D reconstruction for volume estimation	Yes (3D)	Per-dish (can map to nutrition if coupled)	No	Higher accuracy; requires multi-view capture/setup.
Single-View Geometric Models (Fang et al.) [22]	Single RGB image	Single-view geometric priors/models for portion estimation	Approx.	Per-dish (if coupled with nutrient DB)	No	Lightweight classical approach; accuracy depends on assumptions/geometry fit.
CalorieAI (Chandra et al.) [14]	Custom dataset	YOLOv8 detector + image-based calorie estimation	No	Global calories	No	Fast detection-driven pipeline; lacks rigorous geometry/volume computation.
YOLOv5 Calories Estimation (Shams et al.) [16]	(Chapter; dataset not explicit in BibTeX)	YOLOv5-based recognition + calorie estimation	No	Global calories	No	Detection-first approach; accuracy depends on dataset + mapping assumptions.
Mobile Nutrient Analysis (Revesai & Kogeda) [23]	Mobile food images	Lightweight interpretable DL + KD + Grad-CAM/LIME for nutrient estimation	No	Per-dish nutrients (estimation)	Yes (mobile/edge)	Mobile-friendly + interpretable; focuses on nutrients (not explicit volume).
FL for Food Service Industry (Taheri Gorji et al.) [8]	Distributed fluorescence imaging frames	Federated learning (FedAvg) + MobileNetv3/DeepLabv3+	No	N/A (cleanliness auditing)	Yes (FL)	Strong example of FL privacy in food-service vision; not food portion/nutrition.
PET Survey for FL in IoHT (Mosaiyebzadeh et al.) [24]	Survey	Privacy-enhancing technologies for FL in IoHT	No	N/A	Yes (survey)	Summarizes PETs and challenges; background support for privacy motivation.
LDP for FL (Behnia et al., arXiv) [9]	General FL setting	Local Differential Privacy with fixed memory + per-client privacy	No	N/A	Yes (privacy)	Useful privacy method reference for FL; not food-specific.
Mask R-CNN (He et al.) [15]	General vision benchmark work	Instance segmentation backbone (Mask R-CNN)	N/A	N/A	N/A	Core method reference for instance segmentation used by iLog 3.0-style pipelines.
Swin Transformer (Liu et al.) [25]	General image datasets	Transformer-based hierarchical vision model	No	N/A	No	Captures long-range dependencies and improves segmentation performance; not designed for volume or nutrition estimation.
MaskFormer (Cheng et al.) [26]	General vision datasets	Unified segmentation framework (transformer-based)	No	Region-level only	No	State-of-the-art segmentation accuracy; focuses only on segmentation without volume or nutrition computation.

highlights how most existing research in food vision has focused on broad multi-class food detection or image-level calorie estimation. While these studies demonstrate strong recognition accuracy, they generally assume each dish has a fixed calorie value and overlook per-ingredient variability [11]. Several frameworks, such as iLog [4,5], FoodSegDL [12,13], and CalorieAI [14], employ deep detectors or segmentation models like Mask R-CNN [15] and YOLO [16] to identify foods, but they either depend on static calorie tables or require additional sensors for volume estimation. iLog 3.0 [17] improves volume accuracy by incorporating monocular depth estimation, but depth/multi-view components add compute and system complexity that can be tough for lightweight deployments. Only a few works explore federated learning, and even then, they rarely combine FL with detailed nutrient analysis. The proposed iLog 2.2 framework stands out by combining edge deployability, federated privacy, and per-topping macro–micro-nutrient estimation derived from computed volume and weight.

Table 2. Comparison of Commercial Food-Logging Applications.

Application	Input Type	Automation	Insights
See How You Eat [31]	Manual photo logging/visual diary	None (mostly manual)	Primarily a photo-based diary; lacks automatic detection and portion/volume estimation.
Lose It! [27]	Manual logging + barcode scan	Database lookup + barcode-based matching	Good for calorie tracking from known foods; limited vision-based segmentation or portion-size estimation from images.
AteMate [32]	Photo diary entries + manual notes	Manual tagging/habit tracking	Supports qualitative tracking; typically does not compute calories/volume from a single food photo.
Bite AI [30]	Camera input (food photos)	Cloud-based AI recognition (image-to-food labeling)	Convenient recognition, but often cloud-dependent and may not provide robust per-ingredient segmentation or accurate portion volume.
HealthifyMe [29]	Manual logging + AI chat input (text)	Semi-automated recommendations + database-driven logging	Strong diet-plan ecosystem; image-based portion estimation is limited compared to geometry/volume-based research systems.
MyFitnessPal [28]	Manual + barcode scan + voice input	Large database + barcode/recipe features	Widely used food database; does not focus on vision-based segmentation/volume estimation from images.
Yazio [33]	Manual + AI-assisted input (varies by feature)	Partial automation (plans/recipes/database)	Fast tracking and planning; limited in photo-based per-ingredient segmentation and accurate portion quantification.
Foodvisor [34]	Camera + AI model input	Cloud recognition + nutrition estimate	Provides image-based nutrition estimation, but accuracy can depend on cloud model and may not reliably infer portion volume.
EatWise [35]	Manual reminders + meal timing	Manual tracking/reminders	Focuses on eating schedule/behavior; not designed for calorie, macro, or volume estimation from images.

compares popular commercial food-logging applications with the proposed system. These apps, such as Lose It! [27], MyFitnessPal [28], HealthifyMe [29], and BiteSnap [30], primarily rely on manual data entry, barcode scanning, or cloud-based recognition services. Although convenient for casual diet tracking, they provide only approximate calorie information and require user input for portion size. However, most existing methods do not fully support automatic ingredient-level segmentation or nutrient estimation for individual components in mixed dishes. In contrast, the proposed iLog 2.2 model operates fully on the device, accepts images from any camera angle, and uses polygon-based segmentation to compute per-topping volume, weight, and nutritional composition while preserving user privacy through federated learning.

From the above discussion, it can be observed that existing approaches primarily focus on detection or segmentation, often rely on fixed calorie assumptions, or require additional hardware for volume estimation. In addition, limited attention has been given to ingredient-level analysis combined with privacy-preserving learning. The proposed iLog 2.2 framework is designed to address these gaps by integrating instance segmentation, geometric volume estimation, and federated learning into a unified pipeline.

3. Novelty of the Proposed Solution

The proposed system, iLog 2.2, introduces several contributions that differentiate it from existing calorie estimation and nutrition analysis frameworks. Traditional approaches often treat complex meals as single homogeneous entities, providing only approximate calorie estimates. In contrast, iLog 2.2 models the problem at a finer granularity by focusing on ingredient-level analysis within mixed or multi-component meals.

While components such as Mask R-CNN-based segmentation are well-established in prior work, this research focuses on integrating these techniques with geometric volume estimation and federated learning into a unified and lightweight pipeline. This combination enables accurate, interpretable, and privacy-preserving nutrition estimation. The major contributions of this work are summarized as follows:

• Mixed Meal Analysis: Instead of estimating total calories for a meal as a single unit, iLog 2.2 analyzes each visible ingredient individually. This makes it one of the first systems to address calorie estimation for mixed foods, where components vary in thickness, density, and volume.
• Federated Learning for Privacy: The model incorporates a federated learning framework that allows distributed devices to participate in collaborative training without sharing any raw images or personal data. Only encrypted model parameters are communicated, ensuring complete privacy and security of user information. This approach enables large-scale model improvement while fully complying with data protection standards, such as GDPR and HIPAA.
• Lightweight and Edge-Compatible Model: A compact and computationally efficient deep learning model has been designed to operate efficiently on low-power devices and to be deployable in future edge environments. The lightweight nature of the model reduces latency and energy consumption, enabling fast and efficient inference.
• Flexible Image Input: The system accepts images captured from any camera angle, removing the need for fixed reference perspectives or additional calibration objects. This flexibility enhances usability in real-world conditions, where users capture spontaneous food images in uncontrolled settings.
• Polygon-Based Segmentation: Each ingredient is annotated using polygonal masks rather than bounding boxes, allowing precise delineation and improved computation of surface area. The segmentation output directly contributes to the accuracy of subsequent volume and mass estimation.
• No Reference Image Requirement: Unlike depth-based or multi-view estimation systems, iLog 2.2 does not rely on any external reference image or additional camera calibration. The use of preset geometric priors for height and ingredient thickness makes the system simple, efficient, and fully self-contained.
• Volume-to-Weight Conversion: The system converts 2D pixel-based areas into estimated volume using preset height values and then translates the volume into mass (grams) using ingredient-specific density factors. This conversion enables both weight and calorie contribution to be estimated per ingredient.
• Macro- and Micro-Nutrient Estimation: Beyond calorie computation, iLog 2.2 provides a detailed nutrient profile. It calculates macro-nutrients such as carbohydrates, proteins, and fats, and micro-nutrients including sodium, calcium, and iron for each detected component as well as for the complete meal. This approach overcomes the limitations of generalized calorie estimates by providing ingredient-level nutritional breakdowns.
• Dynamic Calorie Estimation: The system accounts for variations in ingredient quantity and distribution. Unlike conventional systems that assume fixed calorie values for standard meals, iLog 2.2 dynamically adjusts its output according to the detected components and their computed weights, resulting in highly personalized and accurate estimates.

Overall, iLog 2.2 redefines calorie and nutrient estimation by combining federated learning, edge-compatible design, and geometric analysis into a unified and scalable framework. It provides a privacy-aware and interpretable solution that not only estimates calories but also generates detailed nutritional insights tailored to each user’s intake.

4. Methodology/Overview of the Proposed Model

The proposed iLog 2.2 model is designed to make food calorie and nutrient estimation simple, accurate, and privacy-preserving for end users. The process begins when a user captures an image of their food using the mobile application. The image is directly uploaded through the user interface to the iLog 2.2 system, where the backend neural network, built on a lightweight Mask R-CNN architecture, processes it to identify and segment individual components of the meal.

Once the image is received, the system automatically detects each visible ingredient and separates it using polygon-based masks to preserve fine detail and boundary precision. These segmented regions are then analyzed to determine their relative area, which is later used to compute volume and mass for nutrient estimation. The entire workflow from image upload to calorie and nutrient breakdown is handled seamlessly by the application without requiring any manual input or external calibration. This design ensures a smooth user experience while maintaining reliability and scalability for everyday use across various food types and real-world lighting or background conditions.

All further computations, such as converting detected topping areas into physical measurements, take place in the model’s processing layer. The detected regions are first analyzed to calculate pixel area, which is then converted to estimated volume using preset height values. This volume is converted into weight (grams), and from this, the model derives calories, macro-nutrients (carbohydrates, proteins, fats), and micro-nutrients (sodium, calcium, iron, etc.) for each topping as well as for the entire pizza. An overview of the proposed system is presented in Figure 3, and the step-by-step development workflow is depicted in Figure 4.

Pizza has been considered in this study as it is a globally consumed food item and serves as a representative example of a mixed meal containing multiple components. The variety of toppings, sauces, and ingredient combinations introduces significant complexity in accurately estimating nutritional values, making it an ideal case for testing the real-world performance of food estimation models.

After the calculations are completed, the processed image, now annotated with identified toppings and their corresponding nutritional values, is sent back to the user through the mobile application’s interface. The user can see the final output image along with detailed nutritional information, including the calories and macro–micro breakdown, making the estimation fully interpretable and personalized.

5. Implementation

5.1. Dataset

This work uses two integrated datasets, one for visual data and the other for nutritional reference values. The image dataset contains a total of 1107 pizza images, captured from different angles and lighting conditions to ensure variety and real-world representation. Out of these, 666 images are used for training, 222 for testing, and the remaining 219 images for validation. This allocation prioritizes learning capacity while maintaining independent validation and testing for fair evaluation.

Every image is manually annotated using polygon masks with 50 labels that represent various toppings, sauces, and cheese types commonly found on pizzas. As shown in Figure 5, the dataset includes a diverse variety of pizzas with multiple topping combinations. The dataset consists of 50 food categories with varying sample distributions across classes, reflecting real-world diversity in food occurrence. Frequently observed toppings such as Pepperoni (4645 samples), Basil (2499 samples), and Cheese (1547 samples) are well represented, while several less common categories have significantly fewer samples. This long-tail distribution captures realistic variation in food composition and supports evaluation under both dominant and sparse class conditions. Since pizza is a multi-component food with diverse topping combinations, the dataset includes a wide range of ingredient co-occurrences to reflect practical, real-world scenarios.

The nutritional dataset is curated from verified public resources such as the U.S. Department of Agriculture (USDA) database [36] and Data.Gov: Food-a-pedia [37]. Nutritional information including calorie values, macro-nutrients (carbohydrates, proteins, fats), and micro-nutrients (sodium, calcium, iron, etc.) was collected for each topping based on multiple portion sizes such as one cup, one slice, and different thickness levels. These values were manually refined to maintain consistency across units and portion categories.

Finally, both datasets were combined to form a single structured dataset that links each annotated topping label with its corresponding nutritional information. This unified dataset enables the iLog 2.2 model to compute accurate calories and nutrients directly from topping-level predictions in the image, ensuring that the visual segmentation output aligns precisely with real nutritional metrics.

5.2. Mask R-CNN Based Detection and Segmentation

The next stage of the system focuses on detecting and segmenting each component present in the image. For this, a customized Mask R-CNN model is used because it can perform both object detection and instance segmentation within a single framework as shown in Algorithm 1. Mask R-CNN has been widely adopted in computer vision tasks for its ability to generate high-quality segmentation masks while maintaining strong detection accuracy [15]. The model identifies every visible topping such as cheese, sauce, onion, tomato, pepper, olive, and others and separates them using polygon masks. Each topping mask is stored with a unique label that links it to its nutritional data.

The image captured from the user’s mobile camera is first resized and normalized before being passed to the Mask R-CNN model. The backbone network extracts deep visual features, while the Region Proposal Network (RPN) [38] generates candidate regions where toppings may exist. The final segmentation head produces binary masks for each detected object, outlining the shape and size of individual toppings accurately.

All detected masks are then post-processed to remove overlaps and false positives. Each topping mask is associated with its class ID and pixel count, which will later be used for volume estimation. Because the model is trained with polygon annotations, it performs well on irregular topping shapes and overlapping regions. The output of this step is the segmented image with labeled toppings and their corresponding pixel areas, which is then passed to the next computation stage for volume and nutrient estimation.

Algorithm 1 Topping Detection and Segmentation using Mask R-CNN

Require: RGB image I (any angle); trained weights W; class list $\mathcal{L}$; score threshold ${\tau }_s$; mask threshold ${\tau }_m$; NMS IoU ${\tau }_n$; minimum area $A_{min}$ Ensure: Set of instances $\mathcal{S}=\left\{({\mathcal{l}}_i,M_i,N_i,{\mathrm{conf}}_i,{\mathrm{bbox}}_i)\right\}$ 1: $I^{\prime }\leftarrow \mathrm{Preprocess}\left(I\right)$                    ▹ resize to $512\times 512$, normalize, optional denoise 2: $\mathcal{R}\leftarrow \mathrm{MaskRCNN}\_\mathrm{Infer}(W,I^{\prime })$            ▹ proposals with class posteriors, mask logits, boxes 3: $\mathcal{R}\leftarrow \mathrm{NMS}(\mathcal{R},\mathrm{IoU}={\tau }_n)$                         ▹ remove redundant detections 4: $\mathcal{S}\leftarrow ⌀$ 5: for each detection $r\in \mathcal{R}$ do 6:       if $\mathrm{score}\left(r\right)<{\tau }_s$ then 7:           continue 8:       end if 9:       $M\leftarrow \mathbf{1}\left(\sigma (r.\mathrm{mask}\_\mathrm{logits})\ge {\tau }_m\right)$                          ▹ binarize mask 10:     $M\leftarrow \mathrm{MorphRefine}\left(M\right)$                      ▹ remove speckles, fill small holes 11:     if $\mathrm{Area}\left(M\right)<A_{min}$ then 12:         continue 13:     end if 14:     $(M,\mathrm{bbox})\leftarrow \mathrm{ClipToImage}(M,I^{\prime })$ 15:     $\mathcal{l}\leftarrow r.\mathrm{class}\_\mathrm{probs}$;   $\mathrm{conf}\leftarrow maxr.\mathrm{class}\_\mathrm{probs}$ 16:     $N\leftarrow \mathrm{PixelCount}\left(M\right)$ 17:     $\mathcal{S}\leftarrow \mathcal{S}\cup \left\{\right(\mathcal{l},M,N,\mathrm{conf},\mathrm{bbox}\left)\right\}$ 18: end for 19: $\mathcal{S}\leftarrow \mathrm{ResolveOverlaps}\left(\mathcal{S}\right)$             ▹ mask-wise soft-NMS or priority by confidence/area 20: return$\mathcal{S}$                           ▹ to volume/weight computation stage

5.3. Volume Estimation

After detecting and segmenting each topping using the Mask R-CNN model, the next important step is to determine the physical volume of each region. The system follows a preset height-based estimation approach, which removes the need for any reference object or external calibration, as shown in Algorithm 2.

Based on prior studies in food geometry and serving thickness, the average height of a standard pizza was determined to be approximately 2 cm, as supported by [39,40]. While preset height assumptions are used in this work, they are based on commonly observed serving dimensions reported in food geometry and nutritional datasets. Although food thickness may vary depending on preparation, using standardized height values provides a practical and computationally efficient approximation for volume estimation without requiring additional sensors or multi-view inputs.

This approach is particularly suitable for lightweight and edge-compatible systems, where minimizing computational complexity is important. Furthermore, minor variations in height are partially compensated through density-based mass conversion and aggregation across multiple toppings.

It is acknowledged that camera perspective and depth distortion can influence area estimation in single-view images. However, the proposed system is designed to operate under unconstrained real-world conditions without requiring calibration or depth sensors, making it more practical for everyday use. Future work can incorporate depth-aware models or multi-view inputs to further improve geometric accuracy.

Using this value as a constant base height ($h_{base}$), the system estimates the height for other toppings proportionally using their recorded serving dimensions in the FoodData Central [36] and Food-a-pedia [37] nutritional datasets. This ensures that each topping has a realistic relative height for computing its volume.

The area for each topping is obtained from the segmentation masks in pixels. The Mask R-CNN output provides a pixel count $N_i$ for each topping i, which is converted to an actual surface area $A_i$ in cm² using a learned scale prior $s^{★}$ (cm/pixel). The relationship is given as:

$$A_i=N_i\times {\left(s^{★}\right)}^2$$

(1)

As shown in Equation (1), $N_i$ represents the number of detected pixels corresponding to topping i, and $s^{★}$ denotes the learned scale factor (cm/pixel) used to convert pixel measurements into real-world dimensions, resulting in the surface area $A_i$ in cm².

The estimated topping height $h_i$ (in cm) is then used to compute the volume $V_i$ of that topping:

$$V_i=A_i\times h_i$$

(2)

As shown in Equation (2), the topping volume $V_i$ is obtained by multiplying the surface area $A_i$ with the estimated height $h_i$, where $h_i$ represents the thickness (in cm) of the i-th topping.

Once the volume is calculated, it is converted into weight (mass) using the corresponding density value ${\rho }_i$ (g/cm³) obtained from the USDA dataset:

$$m_i=V_i\times {\rho }_i$$

(3)

As shown in Equation (3), ${\rho }_i$ denotes the density (g/cm³) of the i-th topping obtained from the USDA dataset, and is used to convert volume into mass.

Since most food nutrient data is standardized in grams, all further calculations use $m_i$ in grams. When applicable, conversions are performed using the equivalence [41]:

$$1\mathrm{cup}=240\mathrm{grams}\left(approx\right)$$

(4)

As shown in Equation (4), this ensures accurate scaling between volume-based and mass-based quantities.

Therefore, the final output of this step is the estimated mass $m_i$ for each topping, which serves as the input for the next module the nutrient and calorie estimation engine, as shown in Equation (3).

Algorithm 2 Volume → Mass (grams) → Nutrients with Preset Height

Require: Segmented instances $\mathcal{S}=\left\{({\mathcal{l}}_i,M_i,N_i)\right\}$; scale prior $s^{★}$ (cm/px); 1:      base height $h_{\mathrm{base}}=2$ cm; topping heights table $\mathcal{H}\left[\mathcal{l}\right]$ (cm, optional); 2:      density table $\rho \left[\mathcal{l}\right]$ (g/cm3); nutrient table $\mathcal{N}\left[\mathcal{l}\right]$ with per-gram factors; 3:      serving conversions $\mathcal{C}$ (e.g., $1\mathrm{cup}=240\mathrm{g}$, tbsp, slice, etc.) Ensure: For each topping i: area $A_i$ (cm2), volume $V_i$ (cm3), mass $m_i$ (g), calories $C_i$ (kcal), macro/micro vector ${\mathbf{n}}_i$; and whole-pizza totals 4: for each instance i with label ${\mathcal{l}}_i$ and pixel count $N_i$ do 5:       $A_i\leftarrow N_i\times {\left(s^{★}\right)}^2$                           ▹ pixel area → physical area (cm2) 6:       $h_i\leftarrow \left\{\begin{array}{cc}\mathcal{H}\left[{\mathcal{l}}_i\right],\hfill & \mathrm{if}\mathrm{available}\hfill \\ h_{\mathrm{base}},\hfill & \mathrm{otherwise}\hfill \end{array}\right.$ 7:       $V_i\leftarrow A_i\times h_i$                           ▹ volume in cm3 (preset/lookup height) 8:       $m_i\leftarrow V_i\times \rho \left[{\mathcal{l}}_i\right]$                            ▹ convert volume to mass (grams) 9:       $(e_{\mathrm{kcal}/\mathrm{g}},{\mathbf{f}}_{\mathrm{per}\mathrm{g}})\leftarrow \mathcal{N}\left[{\mathcal{l}}_i\right]$                  ▹ energy and macro/micro factors per gram 10:     if $\mathcal{N}$ entry is given per serving (cup/slice/tbsp) then 11:         $g_{\mathrm{per}\mathrm{serving}}\leftarrow \mathcal{C}\left[\mathrm{serving}\_\mathrm{type}\right]$                          ▹ e.g., $1\mathrm{cup}=240$ g 12:         Convert factors to per-gram: $e_{\mathrm{kcal}/\mathrm{g}}\leftarrow {\displaystyle \frac{e_{\mathrm{kcal}/\mathrm{serv}}}{g_{\mathrm{per}\mathrm{serving}}}}$; ${\mathbf{f}}_{\mathrm{per}\mathrm{g}}\leftarrow {\displaystyle \frac{{\mathbf{f}}_{\mathrm{per}\mathrm{serv}}}{g_{\mathrm{per}\mathrm{serving}}}}$ 13:     $C_i\leftarrow m_i\times e_{\mathrm{kcal}/\mathrm{g}}$                               ▹ calories for topping i 14:     ${\mathbf{n}}_i\leftarrow m_i\times {\mathbf{f}}_{\mathrm{per}\mathrm{g}}$                      ▹ macro/micro nutrient vector for topping i 15: end for 16: $A_{\mathrm{tot}}\leftarrow {\sum }_i{A}_i$;$V_{\mathrm{tot}}\leftarrow {\sum }_i{V}_i$;$m_{\mathrm{tot}}\leftarrow {\sum }_i{m}_i$ 17: $C_{\mathrm{tot}}\leftarrow {\sum }_i{C}_i$;${\mathbf{n}}_{\mathrm{tot}}\leftarrow {\sum }_i{\mathbf{n}}_i$ 18: return${\left\{(A_i,V_i,m_i,C_i,{\mathbf{n}}_i)\right\}}_i$ and $(A_{\mathrm{tot}},V_{\mathrm{tot}},m_{\mathrm{tot}},C_{\mathrm{tot}},{\mathbf{n}}_{\mathrm{tot}})$

5.4. Nutrient and Calorie Computation

Once the weight of each topping is obtained from the previous step, the system converts these weights into calories and nutrient values using the curated nutritional dataset, as shown in Algorithm 3. The nutrient data for each topping includes calories, proteins, fats, carbohydrates, sodium, calcium, iron, and other macro and micro components, all expressed per gram. These values are collected from the USDA [36] and FoodData Central datasets [37], where each food item is standardized to a per-gram nutritional profile.

For every topping i, the total calorie and nutrient values are computed by scaling the per-gram nutrient factors with the estimated weight $m_i$ in grams. The overall calorie value $C_i$ for each topping is calculated as:

$$C_i=m_i\times E_i$$

(5)

As shown in Equation (5), the total calorie content for each topping is computed by multiplying the estimated mass by its corresponding per-gram energy value (kcal/g), where $E_i$ denotes the per-gram energy value of the i-th topping obtained from the nutritional dataset.

Similarly, the macro and micro nutrients are computed using:

$${\mathbf{n}}_i=m_i\times {\mathbf{f}}_i$$

(6)

As shown in Equation (6), the nutrient vector ${\mathbf{n}}_i$ for each topping is calculated by scaling the per-gram nutrient values, such as protein, fat, carbohydrates, sodium, and calcium, by the mass $m_i$.

Finally, the total nutritional values for the entire pizza are computed by summing all topping contributions:

$$C_{\mathrm{total}}=\sum _i{C}_i,{\mathbf{n}}_{\mathrm{total}}=\sum _i{\mathbf{n}}_i$$

(7)

As shown in Equation (7), the total calorie value $C_{\mathrm{total}}$ and the aggregated nutrient vector ${\mathbf{n}}_{\mathrm{total}}$ represent the complete nutritional profile of the pizza, combining all detected toppings to give per-topping and overall composition.

The advantage of this approach is that it removes the need to assume a fixed calorie count for all pizzas. Instead, each pizza is analyzed individually based on its detected toppings, thickness, and densities. The output image sent back to the user includes visual annotations of the detected toppings, their calories, and the macro–micro distribution, providing a complete and interpretable nutritional report for a single pizza image.

Algorithm 3 Nutrient and Calorie Computation

Require: For each topping i: estimated mass $m_i$ (g); nutrient table $\mathcal{N}$ containing per-gram values for calories $E_i$ and macro/micro vector ${\mathbf{f}}_i$ Ensure: For each topping i: calories $C_i$, nutrient vector ${\mathbf{n}}_i$; and totals for the full pizza 1: for each topping instance i do 2:     $(E_i,{\mathbf{f}}_i)\leftarrow \mathcal{N}\left[{\mathcal{l}}_i\right]$                    ▹ lookup per-gram energy and nutrient factors 3:     $C_i\leftarrow m_i\times E_i$                           ▹ total calories (kcal) for topping i 4:     ${\mathbf{n}}_i\leftarrow m_i\times {\mathbf{f}}_i$                            ▹ scale nutrients to mass in grams 5: end for 6: $C_{\mathrm{total}}\leftarrow {\sum }_i{C}_i$                            ▹ sum of calories for entire pizza 7: ${\mathbf{n}}_{\mathrm{total}}\leftarrow {\sum }_i{\mathbf{n}}_i$                        ▹ aggregate all macro and micro nutrients 8: Annotate output image with $\left\{({\mathcal{l}}_i,C_i,{\mathbf{n}}_i)\right\}$ and total summary 9: return$\{C_i,{\mathbf{n}}_i\}$ for each topping and $(C_{\mathrm{total}},{\mathbf{n}}_{\mathrm{total}})$ for the pizza

5.5. Federated Learning

To maintain user privacy while still improving the model over time, the iLog 2.2 adopts a federated learning (FL) framework. In this setup, as shown in Algorithm 4, all user data such as food images and nutrient outputs remain on the local device. The learning process happens collaboratively across multiple users, where each device trains the model on its own data and shares only encrypted weight updates with the central server. No raw image or nutritional information is ever transmitted, ensuring complete data confidentiality.

This design is particularly important in real-world dietary and healthcare scenarios, where food images and user-specific nutritional data are sensitive and cannot be shared with centralized servers. Federated learning enables collaborative model improvement across distributed users while ensuring that all raw data remains on-device, preserving privacy and supporting compliance with data protection regulations.

During each communication round, the global model with weights $W_t$ is distributed to a group of clients. Each client performs local training on its private dataset and generates an updated weight set $W_t^k$. These updates are securely aggregated on the server using the Federated Averaging (FedAvg) algorithm:

$$W_{t+1}=\sum _{k=1}^K{\displaystyle \frac{n_k}{{\sum }_{j=1}^K{n}_j}}{W}_t^k$$

(8)

As shown in Equation (8), the updated global model weights $W_{t+1}$ are computed as a weighted average of the local client updates, where $n_k$ represents the number of training samples held by the $k\mathrm{th}$ client. This ensures that larger datasets contribute proportionally more to the global update. The process allows the iLog 2.2 model to learn collaboratively from distributed user data while preserving privacy and avoiding centralized data collection.

The federated learning setup also reduces the dependency on cloud computation and can be extended to run on lightweight edge devices, enabling secure, fast, and localized processing of food images in future versions of the system.

Algorithm 4 Federated Learning Update Process (FedAvg)

Require: Global model weights $W_t$ at round t; total K clients; local epochs E; learning rate $\eta$ Ensure: Updated global model $W_{t+1}$ 1: Server broadcasts global weights $W_t$ to selected clients 2: for each participating client $k\in \{1,\dots ,K\}$ in parallel do 3:     Load local dataset ${\mathcal{D}}_k$ 4:     for each local epoch $e=1$ to E do 5:         Compute gradients $\nabla {\mathcal{L}}_k\left(W_t\right)$ on ${\mathcal{D}}_k$ 6:         Update local model: $W_t^k\leftarrow W_t-\eta \nabla {\mathcal{L}}_k\left(W_t\right)$ 7:     end for 8:     Encrypt local update $\Delta W_t^k=W_t^k-W_t$ for privacy 9:     Send $\Delta W_t^k$ (not raw data) to server 10: end for 11: Server aggregates updates using FedAvg: $$W_{t+1}=W_t+\sum _{k=1}^K{\displaystyle \frac{n_k}{{\sum }_{j=1}^K{n}_j}}\Delta W_t^k$$ 12: Distribute new global weights $W_{t+1}$ to all clients 13: return$W_{t+1}$

Implementation Details: For experimentation, the federated learning setup was simulated using three clients representing different user devices, each trained on a subset of the pizza image dataset. The global model was initialized once and updated over two communication rounds. Each client performed one local epoch per round using its private data before sending encrypted model updates to the central aggregator. After aggregation with the FedAvg algorithm, the updated global model showed smoother convergence and improved segmentation accuracy compared to standalone training. This confirms that the proposed federated setup can effectively learn from distributed user data while preserving privacy.

6. Results and Discussion

The proposed iLog 2.2 model was tested on the curated pizza dataset, and the outputs clearly show how the system detects toppings, calculates mass, calories, and finally gives a complete nutrient report for every topping and the total pizza. The model performed well even when the images were taken from different angles, without any reference object or special lighting setup.

Figure 6 shows the output from the Mask R-CNN model, where each topping on the pizza is correctly detected and labeled with its class name and confidence value. As seen, the model identified the pizza base with an approximate 97% confidence and detected every piece of pepperoni and ham topping individually with high accuracy. The color-coded bounding boxes and segmentation masks show that the system can handle overlapping toppings and irregular shapes effectively.

After detection, the next stage converts the topping areas into volume using the preset height and then into mass in grams. The total estimated mass of the pizza was 1128.805 g. Using the mass and nutrient database, the system calculated the calories for each topping and the total pizza.

Table 3. Mass and Calorie Breakdown for Each Component of the Pizza.

Component	Mass (g)	Calories (kcal)
Base (dough)	803.625	2129.605
Cheese layer	206.933	579.413
Sauce layer	118.248	34.292
TOTAL (Combo)	1128.805	2743.31

shows that the combined contribution of the base (dough), cheese layer, and sauce layer results in a total of 2743.31 kcal. Among these, the base (dough) contributes the largest share (2129.605 kcal), followed by the cheese layer (579.413 kcal), while the sauce layer contributes a comparatively smaller amount (34.292 kcal). This demonstrates that the area-based volume estimation effectively scales calorie values according to the component proportions.

Table 4. Macronutrient Breakdown for Each Topping.

Item	Protein (g)	Fat (g)	Sat. Fat (g)	Carbs (g)	Sugars (g)	Fiber (g)
Pizza with Cheese & Sauce	131.92	61.13	5.63	408.26	34.0	23.83
Pepperoni	23.43	44.83	0.0	1.22	0.51	0.0
Ham	1.04	0.26	0.0	0.08	0.05	0.0
TOTAL	156.39	106.22	5.63	409.56	34.56	23.83

presents the macro-nutrient values for each topping, including protein, fat, carbohydrates, sugar, and fiber. The base pizza layer contributes the highest carbohydrate and protein content, while pepperoni mainly adds to the fat content. This detailed breakdown helps understand which components affect calorie distribution the most.

Similarly,

Table 5. Micronutrient Analysis for the Detected Pizza and Toppings.

Item	Sodium (mg)	Calcium (mg)	Iron (mg)	Potassium (mg)	Cholesterol (mg)
Pizza with Cheese & Sauce	5737.25	2342.32	30.62	1551.15	184.17
Pepperoni	1609.78	11.21	1.22	282.22	113.09
Ham	62.31	0.36	0.05	10.9	2.75
TOTAL	7409.34	2353.89	31.89	1844.27	300.01

shows the micro-nutrients including sodium, calcium, iron, potassium, and cholesterol. As expected, the cheese layer and pepperoni are rich in sodium and calcium, while the base and sauce contribute to iron and potassium levels [42]. The total sodium content for the pizza was calculated as 7409.34 mg, which highlights how even a single pizza can contribute significantly to daily sodium intake.

Overall, these results show that iLog 2.2 can accurately detect each topping, calculate its mass, and determine all nutritional details including macros and micros. This makes the model more interpretable, user-friendly, and closer to real-world diet monitoring than traditional calorie estimation methods that only provide a total calorie number without considering each topping separately.

6.1. Detection and Segmentation Accuracy Comparison

To validate the performance of the proposed iLog 2.2 model, detection and segmentation accuracies were compared with existing food recognition frameworks. The comparison was based on standard evaluation metrics such as mean Average Precision (mAP), AP50, and AP75. As summarized in

Table 6. Comparison of Detection and Segmentation Accuracy.

Model/Work	mAP (%)	AP50 (%)	AP75 (%)
Proposed iLog 2.2	96.0/92.0	98.4/94.0	97.8/93.5
iLog 2.0 (Alakananda et al. [5])	60–68	80	—
FoodSegDL (Liu et al.) [12]	68.0	75	—
YOLOv5–EfficientDet (Zhang et al.) [16]	77.4–80	80	70
Mask R-CNN (Chen et al.) [18]	85.4	88	81

, the proposed model achieved a bounding box mAP of 96.0% and a segmentation mAP of 92.0%, outperforming all previous works, including iLog 2.0, FoodSegDL, YOLOv5–EfficientDet, and the standard Mask R-CNN baseline.

These results serve as baseline comparisons with existing methods, demonstrating the performance improvements achieved by the proposed model.

These quantitative comparisons demonstrate that the proposed iLog 2.2 model achieves superior detection and segmentation performance compared to existing methods, while additionally extending the analysis to volume and nutrition estimation, which is not addressed by prior approaches. The strong AP50 and AP75 values demonstrate high spatial precision and consistent mask accuracy even for small and overlapping toppings [43]. These improvements are primarily due to the topping-level dataset, refined polygon annotations, and optimized training parameters designed for single-food detection. Overall, iLog 2.2 provides reliable and detailed segmentation results while maintaining a lightweight and deployable architecture suitable for real-time applications.

6.2. Prototype Results and Application Interface

To demonstrate the usability and potential deployment of the proposed system, a lightweight mobile interface was designed as a prototype mockup using Figma [44] and its AI-assisted design features. This prototype does not represent a fully implemented mobile application but rather a conceptual interface illustrating how users can interact with the system, view detected food items, and access estimated nutritional information. The design incorporates sample outputs generated by the proposed pipeline to showcase the intended functionality and user experience.

The prototype demonstrates the complete user flow and final nutrition analysis in a single unified panel. As illustrated in Figure 7, the process begins with secure user login and image input, followed by automatic topping detection, nutrient computation, and visualization of per-topping calories, macro-nutrients, and micro-nutrients. The final output displays detailed nutritional summaries and meal logging features, allowing users to track their daily intake directly from the application interface.

The prototype visually demonstrates how the iLog 2.2 model can operate as an end-to-end mobile solution for real-time nutrition estimation. From capturing or uploading a single RGB image, the system automatically detects toppings, calculates their volume, converts it to weight, and retrieves macro-nutrient and micro-nutrient values from the curated database. Unlike traditional calorie-tracking apps that rely on manual input or barcode scanning, this approach offers a fully automated and interpretable workflow. The lightweight design, combined with its privacy-preserving architecture, confirms that iLog 2.2 can be efficiently deployed on edge and mobile platforms for practical everyday use.

6.3. Validation and Model Evaluation

The validation stage was carried out using the test dataset containing 219 images. It aimed to verify the detection accuracy, class consistency, and convergence behavior of the proposed lightweight Mask R-CNN network.

The precision–recall (PR) curves in Figure 8 and Figure 9 illustrate the detection precision at two Intersection-over-Union (IoU) thresholds. At IoU = 0.50, the model maintained high performance across major toppings, achieving an Average Precision (AP) of 0.93 for Pizza, 0.69 for Pepperoni, and 0.63 for Black Olives. At a stricter IoU = 0.75 threshold, precision slightly decreased, yet the Pizza and Black Olive classes continued to show strong localization accuracy, indicating that the model generalizes well even under tighter bounding box requirements.

The confusion matrix in Figure 10 illustrates the prediction accuracy and class-wise performance across the detected food components. Strong diagonal dominance is observed for Pizza (0.98), Basil (0.89), and Cheese (0.88), indicating that the model performs consistently for major categories. Moderate recognition accuracy is seen for Pepperoni (0.82), Black-Olive (0.83), and Olives (0.68), while classes such as Tomato (0.56) and Mushrooms (0.52) show slight confusion with visually similar ingredients. Minor misclassifications occur between pairs like Ham–Beef and Mushroom–Olive due to overlapping texture and color similarities. Overall, the matrix confirms stable performance across diverse ingredient types with clear separation in dominant categories.

The training and validation trends in Figure 11 display smooth convergence across all loss components and the learning rate.

• Classification Loss: Rapidly decreased within the first 1000 iterations, stabilizing near 0.8, confirming effective learning of topping features.
• Localization Loss: Gradually converged near 0.5, showing accurate bounding box regression.
• Total Loss: Declined consistently and plateaued without oscillation, validating stable optimization.
• Learning Rate: Followed a warm-up schedule and stabilized around 2.5 × ${10}^{-4}$, ensuring smooth convergence without overshooting.

Overall, the validation results (Figure 8, Figure 9, Figure 10 and Figure 11) confirm that the iLog 2.2 model achieves high detection accuracy, stable convergence, and reliable classification for both frequent and rare toppings, ensuring robustness for real-world food analysis.

6.4. Nutrition Estimation Validation

Evaluation was performed by comparing the model’s predicted nutrient outputs with ground-truth reference values derived from the curated nutritional dataset using a per-nutrient percent-error view, as shown in Figure 12. These results are computed on the held-out test dataset, ensuring evaluation on unseen samples.

All metrics fall within a practical $\pm 15\%$ target band. Calories and sodium show the smallest deviations ($\approx 3.8\%$), carbohydrates remain tight at $\approx 4.0\%$, and protein/fat errors are moderate at $\approx 6.7\%$ and $\approx 8.3\%$. The largest gaps appear for saturated fat ($\approx 10.0\%$) and sugars ($\approx 11.1\%$), which is expected due to recipe variability and label noise in those micro-nutrient annotations. Overall, the model stays well within an application-friendly tolerance while preserving ingredient-level interpretability.

To illustrate the differences more clearly, Figure 13 compares the predicted values with the ground truth. Bars for calories, carbs, protein, fat, saturated fat, sugars, and sodium track closely, with the biggest visible spread in sugars and saturated fat. This aligns with the percent-error view and reflects natural variation in ingredient formulations (e.g., sauce and cheese brands) and preset-height assumptions used during volume–mass conversion. Despite these factors, the model consistently preserves rank order across nutrients, which is important for practical diet feedback.

These results demonstrate that the proposed iLog 2.2 framework achieves accurate segmentation along with reliable volume and nutrition estimation, providing a practical improvement over traditional approaches that rely on fixed calorie assumptions or lack ingredient-level analysis. Since nutritional values are computed from estimated mass, which is derived from volume, the low error in nutrient estimation also indicates reliable volume approximation in the absence of direct ground-truth volume measurements. Percent-error metrics are used in this work as they provide a normalized and interpretable measure of deviation across different nutrient scales, making them suitable for evaluating both macro- and micro-nutrient estimation.

7. Conclusions and Future Scope

This work presented iLog 2.2, an advanced food analysis framework that focuses on estimating macro-nutrients and micro-nutrients from single RGB images of pizzas. The proposed model uses a lightweight Mask R-CNN network integrated with a federated learning approach, making it privacy-preserving and suitable for mobile or edge-based deployment. Unlike earlier versions of iLog and other calorie estimation systems that rely on preset values or manual entry, this work performs per-topping detection, converts the calculated volume into mass, and computes the nutritional composition using curated USDA and Food-a-pedia datasets.

While the current dataset is focused on pizza-based samples, it serves as a representative multi-component food scenario for evaluating ingredient-level analysis. The dataset size and diversity capture realistic topping combinations; however, future work will explore larger and more diverse public food datasets to further improve generalization across broader food categories.

The current federated learning setup is designed as a proof-of-concept to demonstrate the feasibility of privacy-preserving training within the proposed framework. A limited number of clients and communication rounds are used to maintain computational efficiency and align with edge-device constraints. Future work will explore larger-scale federated settings with increased client participation, communication rounds, and heterogeneous data distributions.

The model achieved high accuracy during validation, reaching a mean Average Precision (mAP) of 96% for bounding box detection and 92% for segmentation. The prototype application demonstrated the real-world usability of the system by automatically detecting pizza components, displaying their mass, calories, and nutritional composition in an intuitive mobile interface. This ensures fast, interpretable, and privacy-preserving nutritional tracking for users and healthcare professionals.

In the future, iLog 2.2 can be extended to include multi-food segmentation and meal-level analysis, enabling the system to identify mixed cuisines beyond pizzas. The integration of real-time inference through edge AI devices, such as NVIDIA Jetson and mobile NPUs, can further reduce cloud dependency. Enhancing the federated learning module with adaptive aggregation techniques and user-specific personalization will strengthen privacy and model performance. Future work will explore improving the reliability and robustness of AI-driven nutrition estimation systems, particularly in real-world deployment scenarios. Additionally, incorporating temporal food logs and integrating physiological or lifestyle data could open possibilities for a complete personalized nutrition monitoring ecosystem. The quantitative results confirm that the proposed system achieves both high detection accuracy and low nutrition estimation error, validating its effectiveness for real-world dietary monitoring applications.

Overall, iLog 2.2 demonstrates that AI-driven nutrition estimation can move beyond calorie counting to precise ingredient-level nutritional understanding, setting a foundation for future smart healthcare and dietary monitoring systems.