Skip to content

SciPY 2025 Notes #7

@ianhi

Description

@ianhi

Notes from SciPY 2025 Sprints.

These are the auto generated notes from an audio recording of the meeting at the scipy 2025 sprints.


⚠️ AI Generated Notes: These notes were generated automatically by AI and may contain errors.

📝 Napari & Xarray Integration Strategy Meeting

Date: July 12, 2025
Attendees: Ian, Beth, Carol, Nodar, Tim, Peter

Notes generated by Gemini from a transcript from a phone recording from the table.

🌟 Meeting Overview

This meeting focused on a crucial technical discussion regarding the integration of the Xarray Python library with the Napari image viewer. The core challenge identified is bridging the gap between Napari's current index-based dimension model and Xarray's powerful capabilities for named dimensions, coordinates, and rich metadata. The group collaboratively formulated a strategic roadmap, outlining steps from a minimal viable product (MVP) to long-term architectural changes, all aimed at making the user experience more intuitive and powerful for both bioimaging and geospatial data analysis.

🛣️ The Path Forward: Project Roadmap

The team outlined a phased approach to integrate Xarray with Napari, progressing from simpler enhancements to more fundamental changes.

Step 1: Basic Metadata Mapping (Proof of Concept)

  • Goal: Ingest Xarray data into Napari's layer metadata to provide immediate context to the user.
  • Key Functionality:
    • Auto-label sliders with Xarray dimension names (e.g., 'Z', 'Time').
    • Assign layer names from Xarray's .name attribute.
  • Implementation Difficulty: Low
  • Notes: Considered the easiest first step as it requires no deep changes to Napari's core and can be implemented in a simple script or plugin.

Step 2: Meaningful Physical Units (Enhancement)

  • Goal: Display physical units on sliders and axes, moving beyond simple pixel indices.
  • Key Functionality:
    • Show slider values as physical units (e.g., '20.5 microns').
    • Automatically configure Napari's scale bar using Xarray scale/unit info.
  • Implementation Difficulty: Medium
  • Notes: This is harder as it involves Napari's viewer dims model, which is more complex than the layer metadata. Current Napari limitations prevent non-linear or categorical (string-based) sliders.

Step 3: "Magic" Reordering (Feature Development)

  • Goal: Intelligently reorder dimensions to match a user's intuitive expectation.
  • Key Functionality:
    • Take an Xarray with an arbitrary dimension order (e.g., XYZC) and display it in a conventional order in the viewer (e.g., sliders for C and Z, display YX).
  • Implementation Difficulty: High
  • Notes: This is a significant jump in complexity due to the "magic" involved. The system needs to correctly guess user intent, which can be challenging.

Step 4: Big Lift: New Dims Model (Long-Term Goal)

  • Goal: Fundamentally change Napari's internal data model to be name-aware instead of index-aware.
  • Key Functionality:
    • Preserve named dimensions and their relationships through transformations like slicing or max projections.
    • Persist user-defined dimension mappings and schemas across sessions.
    • Introduce 'personas' or 'modes' (e.g., Microscopy, Geospatial) for pre-configured dimension handling.
  • Implementation Difficulty: Very High
  • Notes: This is a major architectural change that would solve many core user pain points but requires significant effort. This has been a long-standing challenge with open issues for years.

🧠 Key Challenges & Concepts

Several important concepts and challenges were discussed, forming the foundation of the integration strategy.

  • The Core Problem:
    • Summary: The fundamental conflict between Napari's index-based dimension system and Xarray's named, metadata-rich dimensions.
    • Details: Napari has two separate concepts: layer dimensions and viewer dimensions. The viewer's state (which controls the UI sliders) is based on numerical indices (0, 1, 2...) and is determined by the bottom-most layer. This state is fragile and is lost or reset when layers are added or removed. Xarray objects, however, have persistent, named dimensions ('time', 'channel', 'z'). The goal is to make the Napari viewer respect and preserve Xarray's more descriptive model.
  • Magic vs. Trust:
    • Summary: The debate between automatically mapping data ('magic') versus requiring user confirmation to build trust.
    • Details: While the ultimate goal is for Napari to 'just work' by automatically interpreting the Xarray metadata correctly, the group agreed that this 'magic' risks breaking user trust if it guesses wrong. The consensus for the initial proof-of-concept is to propose a mapping to the user and require a confirmation click, ensuring the user is always in control and understands what is happening to their data.
  • User Pain Points:
    • Summary: Key frustrations users face with Napari's current model that Xarray integration aims to solve.
    • Details: Users are often confused by Napari's behavior. They think in physical units (microns), not pixels. Re-indexing dimensions (like Fiji's 'stack to hyperstack') is difficult. Performing a dimensionality reduction (e.g., max projection) can lead to unexpected and incorrect dimension mappings in the viewer. Xarray's named dimensions are key to solving these issues by maintaining context throughout data transformations.
  • The Vision: 'Personas':
    • Summary: A long-term goal for pre-configured, domain-specific Napari environments.
    • Details: The idea is to allow users to switch Napari into different 'modes' or 'personas', such as 'Microscopy Mode' or 'Geospatial Mode'. Each persona would have pre-configured knowledge about standard dimension names and conventions for that field (e.g., TCZYX for microscopy, latitude/longitude for geospatial). This would provide smart, domain-specific behavior even for simple data arrays that don't come with rich Xarray metadata, decoupling the viewer's intelligence from the data reader.

🚀 Action Items & Ownership

To ensure progress, key tasks were assigned to team members. The list below details the specific responsibilities for each person.

Ian:

  • Write PoC Plan (HackMD)
  • Write Blog Post (co-owner with Tim)
  • Geospatial Sanity Check (ensure compatibility with geospatial data)

Tim:

  • Lead PoC Implementation (initial script/plugin for basic metadata mapping)
  • Write Blog Post (co-owner with Ian)

Carol:

  • Co-own PoC Repo Setup (help establish the napari-xarray GitHub repository)
  • HackMD plan

Nodar:

  • Discuss Multi-scale Integration (future discussion on integrating Xarray's multi-scale capabilities)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions