updating alt-text and captions

Author: anupras-mohapatra-arm

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/1-what-is-model-explorer.md

@@ -46,7 +46,7 @@ For Ethos-U, the ExecuTorch backend uses the Ethos-U Vela compiler to compile TO
 
 TOSA is not inherently ExecuTorch-specific. TOSA is an intermediate representation (IR) that can sit between a model frontend and an Arm backend compiler or converter. ExecuTorch can lower supported graph partitions to TOSA, but another framework can also provide its own TOSA exporter and generate `.tosa` files.
 
-```output
+```text
       PyTorch model
         |
         v
@@ -62,7 +62,7 @@ TOSA is not inherently ExecuTorch-specific. TOSA is an intermediate representati
                                        |
                                        |
                                        |
-      Alternative (non PT/ET)          v
+      Alternative (non PyTorch/ExecuTorch)          v
       frontend with TOSA export ---> TOSA (.tosa)
                                       |
                                       |

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/3-open-and-inspect-cortex-m-pte.md

@@ -48,17 +48,17 @@ To inspect the Cortex-M PTE, follow these steps:
 
 1. In Model Explorer, open `ml-model-artifacts/pte/mv2_cortex_m.pte`.
 
-  ![Screenshot of Model Explorer with Arm Adapters and a loaded Cortex-M PTE.#center](model_explorer.png "Model Explorer with Arm Adapters")
+  ![Model Explorer Select Models screen showing the TOSA, VGF, and PTE extensions loaded and mv2_cortex_m.pte selected, ready to open with View selected models.#center](model_explorer.png "Model Explorer with the Arm adapters and Cortex-M PTE selected")
 
 2. Select **View selected models**.
 
-  ![Screenshot of top-level view in Model Explorer of a loaded Cortex-M PTE.#center](cortex_m_top.png "Typical top-level graph view in Model Explorer")
+  ![Top-level Cortex-M PTE graph showing Graph Inputs, the collapsed forward layer, and Graph Outputs. Expand forward to inspect the execution graph.#center](cortex_m_top.png "Top-level Cortex-M PTE graph")
 
   The graph information panel shows the **op node count** and **layer count**. The **op node count** is the number of operator nodes in the graph. The **layer count** is the number of hierarchical graph components represented in the current view, not necessarily the number of neural network layers in the original model.
 
 3. Expand the `forward` layer to view its operators. Select an operator, such as `cortex_m::quantize_per_tensor`, to see its attributes, inputs, and outputs in the node information panel.
 
-  ![Screenshot of examining a specific Cortex-M operator in Model Explorer.#center](cortex_m_inspect.png "Inspecting specific operators with Model Explorer")
+  ![Expanded Cortex-M graph with cortex_m::quantize_per_tensor selected. The node information and View on nodes panels expose its attributes, inputs, outputs, and KernelCall metadata.#center](cortex_m_inspect.png "Cortex-M operator metadata in Model Explorer")
 
   When you inspect a `.pte` for the first time, focus on the higher-level graph information first:
 

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/4-compare-portable-xnnpack-pte.md

@@ -57,7 +57,7 @@ Inspect the graph and look for the following:
 
 The following is a small snippet image:
 
-![Screenshot of examining a portable Cortex-A PTE in Model Explorer.#center](portable.png "Inspecting portable Cortex-A PTE with Model Explorer")
+![Portable OPT-125M PTE graph showing ATen KernelCall nodes and no XNNPACK delegate regions, establishing the default CPU execution baseline.#center](portable.png "Portable OPT-125M execution graph")
 
 In the artifact, notice the following:
 
@@ -83,7 +83,7 @@ Inspect the graph and look for the following:
 
 The backend has changed the execution plan:
 
-![Screenshot of examining an XNNPACK Cortex-A PTE in Model Explorer.#center](xnnpack.png "Inspecting XNNPACK Cortex-A PTE with Model Explorer")
+![XNNPACK OPT-125M graph showing multiple XnnpackBackend delegate calls interleaved with ATen operators, demonstrating partial and fragmented CPU delegation.#center](xnnpack.png "Fragmented XNNPACK delegation in OPT-125M")
 
 - The top-level graph is smaller than the portable graph, with about 335 operator nodes instead of about 600.
 - The graph contains many `XnnpackBackend` nodes. In this artifact, these represent the delegated regions that'll execute through XNNPACK.
@@ -92,7 +92,7 @@ The backend has changed the execution plan:
 - Some `aten::` operators still remain at the top level, including shape, masking, normalization, and elementwise operations. These are the parts of the graph that stayed on the default ExecuTorch path.
 - The graph isn't one single XNNPACK region. OPT-125M is a transformer with attention, masking, reshapes, and layout changes, so delegation is useful but fragmented into many backend regions.
 
-![Screenshot of examining an XNNPACK subgraph in Model Explorer.#center](xnnpack_subgraph.png "Inspecting XNNPACK subgraph with Model Explorer")
+![Expanded XNNPACK delegate subgraph showing backend operators that replace supported regions of the portable ExecuTorch graph.#center](xnnpack_subgraph.png "Operators inside an XNNPACK delegate region")
 
 This is the key difference to notice: XNNPACK doesn't replace the whole `.pte`. It captures supported subgraphs and leaves the rest of the program in ExecuTorch. In performance work, the balance between large delegated regions and remaining default-path operators is often more important than the raw number of delegate nodes.
 

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/5-inspect-ethosu-pte.md

@@ -40,7 +40,7 @@ Inspect the graph and look for the following:
 - The input and output shapes
 - What this tells you about targeting Ethos-U without quantization
 
-![Screenshot of examining an FP32 Ethos-U PTE in Model Explorer.#center](ethos_fp32.png "Inspecting FP32 Ethos-U PTE with Model Explorer")
+![FP32 MobileNetV2 PTE graph showing ATen convolution and normalization operators with no EthosUBackend node, confirming that the FP32 workload was not delegated.#center](ethos_fp32.png "FP32 MobileNetV2 without Ethos-U delegation")
 
 Ethos-U execution expects quantized integer workloads. This artifact was generated from an FP32 MobileNetV2 model, so the graph isn't in the form Ethos-U needs for NPU execution. As a result, the work remains outside an Ethos-U delegate region.
 
@@ -65,7 +65,7 @@ Inspect the graph and look for the following:
 - Inputs and outputs that cross the delegate boundary
 - Whether any visible work remains outside the delegated region
 
-![Screenshot of examining an INT8 Ethos-U PTE in Model Explorer.#center](ethosu-int8-clean.png "Inspecting INT8 Ethos-U PTE with Model Explorer")
+![INT8 MobileNetV2 graph showing a quantize operation, one EthosUBackend delegate, and a dequantize operation, indicating clean NPU delegation.#center](ethosu-int8-clean.png "Clean INT8 Ethos-U delegation")
 
 A clean delegated example should have most supported quantized work inside the Ethos-U region. In this example, the compute-heavy quantized CNN operators are suitable for Ethos-U and appear as one large delegated region.
 
@@ -91,7 +91,7 @@ Inspect the graph and look for the following:
 - Unsupported operations or graph patterns outside the NPU delegate
 - Quantize, dequantize, or non-delegated operators between delegate regions
 
-![Screenshot of examining a fragmented INT8 Ethos-U PTE in Model Explorer.#center](ethos-u-int8-fragmented.png "Inspecting fragmented INT8 Ethos-U PTE with Model Explorer")
+![Fragmented INT8 graph showing two EthosUBackend regions separated by dequantization, aten::avg_pool3d, and requantization. The unsupported work splits the NPU path.#center](ethos-u-int8-fragmented.png "Ethos-U regions split by non-delegated work")
 
 Fragmentation often means that the model was only partly suitable for the target backend. Common causes include unsupported operators, unsupported tensor shapes, quantization issues, or target-specific compiler constraints.
 

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/6-inspect-tosa.md

@@ -39,7 +39,7 @@ Inspect the graph and look for the following:
 - Whether the tensor types are FP32
 - What convolution, add, clamp, and pooling patterns are visible
 
-![Screenshot of examining an FP32 MobileNetV2 TOSA artifact in Model Explorer.#center](tosa_ethos_fp32.png "Inspecting FP32 TOSA with Model Explorer")
+![FP32 MobileNetV2 TOSA graph showing TRANSPOSE, FP32 CONV2D, and arithmetic operators before Ethos-U compilation.#center](tosa_ethos_fp32.png "FP32 MobileNetV2 represented in TOSA")
 
 The artifact shows that the FP32 model can be represented in TOSA. In Model Explorer, you'll see a large graph with about 800 nodes. Most of the graph is made from constants and arithmetic around the MobileNetV2 operator structure: `CONV2D`, `DEPTHWISE_CONV2D`, `MUL`, `ADD`, `SUB`, `CLAMP`, one `AVG_POOL2D`, and a final `RESHAPE`.
 
@@ -54,7 +54,7 @@ Compare it with the FP32 TOSA graph:
 - You'll see many `RESCALE` operations, which are common in quantized graphs.
 - You'll still see the core CNN structure, including `CONV2D`, `DEPTHWISE_CONV2D`, `ADD`, `AVG_POOL2D`, and `RESHAPE`.
 
-![Screenshot of examining an INT8 MobileNetV2 TOSA artifact in Model Explorer.#center](tosa_ethos_int8.png "Inspecting INT8 TOSA with Model Explorer")
+![INT8 MobileNetV2 TOSA graph showing CONV2D with INT32 accumulation followed by RESCALE, a characteristic quantized-graph pattern.#center](tosa_ethos_int8.png "Quantized MobileNetV2 TOSA graph")
 
 The INT8 graph is still a full MobileNetV2 graph, but the operator mix changes. You'll see fewer floating-point arithmetic nodes and many `RESCALE` nodes. These are used in quantized graphs to move values between quantization scales after integer operations. The convolution and depthwise convolution operators use INT32 accumulation, which is typical for INT8 convolution workloads.
 
@@ -74,9 +74,9 @@ Inspect both TOSA files and look for the following:
 - The fragment that represents the graph region after the inserted LRN-related work
 - Whether the fragment boundaries are consistent with the two `EthosUBackend` regions in the `.pte`
 
-![Screenshot of examining the first fragmented INT8 TOSA artifact in Model Explorer.#center](tosa_ethos_int8_frag_1.png "Inspecting the first fragmented INT8 TOSA artifact")
+![Smaller TOSA fragment from the LRN example showing shape transformation and rescaling operations after the unsupported graph region.#center](tosa_ethos_int8_frag_1.png "Smaller TOSA fragment after the graph split")
 
-![Screenshot of examining the second fragmented INT8 TOSA artifact in Model Explorer.#center](tosa_ethos_int8_frag_2.png "Inspecting the second fragmented INT8 TOSA artifact")
+![Larger TOSA fragment from the LRN example showing the main quantized convolution path with CONV2D and RESCALE operations.#center](tosa_ethos_int8_frag_2.png "Main MobileNetV2 TOSA fragment")
 
 The first LRN TOSA file is the smaller fragment. It has two inputs, with shapes `[1, 1280, 7, 7]` and `[1, 1, 1280, 7, 7]`, and one `[1, 1000]` output. The file contains the later part of the graph after the inserted LRN-related work, including a small number of `RESCALE`, `TABLE`, `MUL`, `AVG_POOL2D`, and `CONV2D` operations.
 
@@ -133,7 +133,7 @@ These small upscaler graphs are INT8 TOSA artifacts. In Model Explorer, look for
 - `RESCALE` operations from quantized arithmetic
 - Similarities and differences between the PTQ and QAT artifacts
 
-![Screenshot of examining a PTQ small upscaler TOSA artifact in Model Explorer.#center](tosa_ptq.png "Inspecting a PTQ small upscaler TOSA artifact with Model Explorer")
+![PTQ upscaler TOSA graph showing shape constants feeding a bilinear RESIZE, followed by RESCALE and quantized convolution operations.#center](tosa_ptq.png "PTQ neural-upscaler graph in TOSA")
 
 Don't expect a major visual difference between the PTQ and QAT TOSA graphs. They represent the same small upscaler architecture and were lowered to the same visible TOSA structure: 41 nodes, including one bilinear `RESIZE`, three `CONV2D` operations, four `RESCALE` operations, three `CONST_SHAPE` nodes, and constants for weights and quantization parameters.
 

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/7-inspect-vgf.md

@@ -38,15 +38,15 @@ Inspect the graph and look for the following:
 - Whether the top-level graph shows the internal upscaler operators
 - What this view tells you about the ExecuTorch runtime path
 
-![Screenshot of examining a VGF-backed PTE in Model Explorer.#center](ptq_vgf_pte.png "Inspecting a VGF-backed PTE with Model Explorer")
+![ExecuTorch PTE graph showing quantization, a single VgfBackend delegate call, and dequantization, indicating that the upscaler is delegated to the VGF backend.#center](ptq_vgf_pte.png "VGF backend packaged inside an ExecuTorch PTE")
 
 In Model Explorer, the `.pte` looks compact. You'll see a `quantized_decomposed::quantize_per_tensor` node, a single `VgfBackend` delegate node, a `quantized_decomposed::dequantize_per_tensor` node, and graph inputs and outputs.
 
 This is similar to the Ethos delegation. Apart from inputs and outputs and the quantize and dequantize operators, the model is completely delegated to the backend.
 
 Expand the `VgfBackend` delegate graph:
 
-![Screenshot of examining the VGF backend subgraph inside a PTE in Model Explorer.#center](ptq_vgf_pte_subgraph.png "Inspecting the VGF backend subgraph inside a PTE")
+![Expanded VGF backend graph showing an input tensor descriptor with shape 1 by 16 by 16 by 3 and VK_FORMAT_R8_SINT, followed by Resize and Rescale operations.#center](ptq_vgf_pte_subgraph.png "VGF tensor descriptor and backend operators")
 
 Now, open the matched standalone VGF artifact `ml-model-artifacts/vgf/small_upscaler_ptq.vgf`.
 

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/8-etrecord-etdump-overlays.md

@@ -191,7 +191,7 @@ Inspect the graph and profiling overlay, then look for the following:
 - Repeated operators that dominate the profile
 - How the runtime view compares with the portable `.pte` view that you inspected
 
-![Screenshot of examining portable OPT-125M ETRecord and ETDump overlays in Model Explorer.#center](portable_profile.png "Inspecting portable OPT-125M runtime overlays")
+![Portable OPT-125M ETRecord graph with ETDump timing tables. No delegate layer is present, and runtime measurements map directly to native model operators.#center](portable_profile.png "Portable OPT-125M runtime profile")
 
 This is a pure portable CPU run. The ETDump contains about 1,199 events, with `Method::execute` around 9,082 ms. There are no delegate calls. Almost all runtime is in native calls, with repeated `aten.addmm` events forming the main hotspot.
 
@@ -208,7 +208,7 @@ Compare it with the portable profile and look for the following:
 - Native operators that still run outside the delegate
 - How much faster this run is than the portable CPU baseline
 
-![Screenshot of comparing XNNPACK OPT-125M ETRecord and ETDump overlays in Model Explorer.#center](xnnpack_profile.png "Inspecting XNNPACK OPT-125M runtime overlays")
+![XNNPACK OPT-125M profile showing many executorch_call_delegate nodes and timing overlays, confirming that most model execution moved into delegate calls.#center](xnnpack_profile.png "XNNPACK delegate calls in the OPT-125M profile")
 
 The XNNPACK ETDump contains about 813 events, with `Method::execute` around 125 ms. The profile includes 98 delegate calls to `XnnpackBackend`. Delegate calls account for about 116.7 ms, while native calls account for about 8.5 ms.
 
@@ -227,7 +227,7 @@ Look for the following:
 - A large `Method::execute` total
 - Runtime behavior that matches the FP32 `.pte` view from the Ethos-U section
 
-![Screenshot of examining an FP32 MobileNetV2 ETRecord and ETDump overlay in Model Explorer.#center](fp32_profile.png "Inspecting FP32 MobileNetV2 runtime overlays")
+![FP32 MobileNetV2 profile showing native feature and classifier layers with no Ethos-U delegate region. The timing table attributes runtime to CPU operators.#center](fp32_profile.png "FP32 MobileNetV2 profile without Ethos-U delegation")
 
 The ETDump contains about 309 events, with `Method::execute` around 395 million cycles. There are no delegate calls, and the native call sum accounts for almost all of the runtime. The profile is dominated by CPU-side convolution work.
 
@@ -242,7 +242,7 @@ Inspect the overlay and look for the following:
 - Whether the largest runtime cost comes from the NPU event or from CPU-side quantization
 - How this compares with the clean INT8 `.pte` view
 
-![Screenshot of examining a clean INT8 Ethos-U ETRecord and ETDump overlay in Model Explorer.#center](ethos_int8_profile.png "Inspecting clean INT8 Ethos-U runtime overlays")
+![INT8 MobileNetV2 profile showing one EthosUBackend partition. The timing overlay shows that CPU-side quantization costs more than dequantization around the delegate.#center](ethos_int8_profile.png "Single Ethos-U partition with CPU-side quantization")
 
 This is the clean Ethos-U delegation case. The ETDump is small, with about 13 events. `Method::execute` is around 6.59 million cycles. There's one `EthosUBackend` delegate call, and only a small number of native calls.
 
@@ -259,7 +259,7 @@ Compare it with the clean INT8 profile and look for the following:
 - How large the non-delegated native cost is compared with the NPU cost
 - Whether quantize and dequantize events appear around delegate boundaries
 
-![Screenshot of examining fragmented INT8 Ethos-U ETRecord and ETDump overlays in Model Explorer.#center](ethos_lrn_profile.png "Inspecting fragmented INT8 Ethos-U runtime overlays")
+![Fragmented MobileNetV2 profile showing two Ethos-U partitions, LocalResponseNorm, and two delegate calls. The timing table exposes expensive work outside the NPU partitions.#center](ethos_lrn_profile.png "Fragmented Ethos-U profile with non-delegated work")
 
 Fragmentation can affect performance in different ways. Additional delegate boundaries can introduce data conversion, synchronization, or tensor movement. Non-delegated operators can also dominate runtime when their execution cost is much larger than the delegated work. Which effect matters most depends on the model, backend, and runtime.
 
@@ -273,4 +273,4 @@ You've learned that ETRecord and ETDump add runtime context to static graphs. ET
 
 The OPT-125M profiles made the CPU case clear: the portable run stayed on native operators, while the XNNPACK run moved most of the work into delegate calls. The MobileNetV2 profiles showed the same pattern for Ethos-U. Native CPU execution, clean Ethos-U delegation, and fragmented delegation are much easier to tell apart when the runtime data is overlaid on the exported graph.
 
-You can now explore deeper workflows for generating, running, profiling, and optimizing your own models.
+You can now explore deeper workflows for generating, running, profiling, and optimizing your own models with Model Explorer.

content/learning-paths/cross-platform/explore-model-artifacts-with-model-explorer/_index.md

@@ -1,5 +1,5 @@
 ---
-title: Visualize ExecuTorch, TOSA, and VGF artifacts with Google Model Explorer and Arm extensions
+title: Inspect model artifacts and runtime profiles with Google Model Explorer and Arm extensions
 
 description: Inspect ExecuTorch PTE, TOSA, VGF, ETRecord, and ETDump model artifacts with Google Model Explorer and Arm extensions.
 
@@ -16,6 +16,7 @@ learning_objectives:
 prerequisites:
   - Python 3.10, 3.11, or 3.12
   - Basic familiarity with PyTorch, ExecuTorch, or model deployment workflows
+  - Git Large File Storage (LFS)
 
 author:
   - Matt Cossins