N.I.N.A. (Nighttime Imaging 'N' Astronomy)

N.I.N.A. is a modular astrophotography suite designed to streamline image acquisition. It supports various astronomy workflows including:

• Equipment control
• Imaging
• Sequencing
• Plate solving
• Plugin-based extensions

While originally designed for Deep Sky Object (DSO) imaging, it has expanded to support a wide range of astrophotography needs.

NINA.Benchmark is a standalone developer tool used for repeatable performance checks via BenchmarkDotNet. It is an executable designed for measuring costs, not verifying correctness (use NINA.Test for functional and numerical assertions).

Important: This project is not part of the NINA application runtime; it is not referenced by, copied into, or packaged with the main NINA application.

Build Configuration:
- Target framework: `net10.0-windows`
- Output type: executable
- Platform target: `x64`
- WPF enabled (for measuring production render paths)

The NINA.Astrometry project is a domain-specific library containing astronomy logic and data access helpers. It is designed as a pure library and is not an application shell or device layer.

Technical Specifications:

• Target Framework: net10.0-windows
• Output Type: Library (WPF enabled)

Core Responsibilities:

• Coordinate and Angle Types: Handling Angle, Coordinates, TopocentricCoordinates, Location, RectangularCoordinates, and WorldCoordinateSystem.
• Astronomy Calculations: Utilities for twilight, nighttime, meridian flips, moon info, and observer info.
• Solar System Models: Models for the Sun, Moon, Earth, and other celestial bodies.
• Catalog/Domain Models: Models for DeepSkyObject, FocusTarget, Constellation, and Star.
• Data Access: SQLite-backed interaction for astronomical data.

The NINA.Test project is an NUnit-based testing suite designed to exercise code across nearly all NINA.* runtime assemblies. It serves as a verification layer rather than a reusable library.

Build Configuration:

• Target Framework: net10.0-windows
• Test Framework: NUnit
• Platform Target: x64

Organization: Tests are organized into a folder structure that mirrors the production code areas (e.g., AstrometryTest/, Autofocus/, Equipment/, Sequencer/). When adding new tests, place them in the folder corresponding to the production area being tested to ensure failures are easy to navigate.

The NINA project is the executable shell. It is organized into the following functional areas:

• ViewModel/: Orchestration view models (e.g., ApplicationVM, DockManagerVM, ImagingVM, Plugins/PluginsVM, Sequencer/SequenceNavigationVM).
• View/: WPF XAML views for the shell and feature areas.
• Resources/: Application-level styles, icons, and images.
• Database/: SQL scripts for initialization and migrations.
• Sequencer/Examples/: Built-in JSON sequence templates.
• External/ and Utility/: Native DLLs and helper executables (e.g., exiftool.exe).

Dependency Rule: NINA depends on almost all library projects (e.g., NINA.Core, NINA.Equipment, NINA.Plugin). Do not place reusable abstractions in the NINA project; move them to the appropriate library project.

NINA.Core is the foundational shared library for the NINA ecosystem. It serves as the lowest-level layer in the NINA.* stack, providing common utilities, shared models, enums, localization, logging, and database configurations.

Because almost all other NINA projects (such as NINA.Equipment, NINA.Sequencer, and NINA.Plugin) depend on it, it is designed for broadly reusable primitives rather than application-specific logic.

Key characteristics:

• Target Framework: net10.0-windows (WPF enabled)
• Dependencies: It has no NINA.* project references; dependencies must always point outward from this project to avoid circular dependencies.

The NINA.Plugin project serves as the plugin contract and runtime infrastructure for N.I.N.A. It manages the entire lifecycle of a plugin, including discovery, loading, compatibility checks, installation, updates, and removal.

Plugins are used to extend the application by providing:

• Sequence Entities: Items, conditions, triggers, and containers (ISequenceItem, ISequenceCondition, ISequenceTrigger, ISequenceContainer).
• UI Components: Dockable view models (IDockableVM) and ResourceDictionary files.
• Behaviors and Equipment: Pluggable behaviors (IPluggableBehavior) and equipment providers (IEquipmentProvider).

When developing a plugin, you derive from PluginBase, which handles the identity and descriptive metadata of your plugin.

NINA.WPF.Base serves as the shared WPF infrastructure layer for the NINA application and its plugins. It acts as a bridge between low-level logic libraries and the application's user interface.

Key responsibilities include:

• Providing shared View-Model base types.
• Implementing the Mediator pattern for decoupled communication.
• Hosting the Sky Survey subsystem for imagery retrieval and caching.
• Offering reusable UI components (equipment panels, autofocus support, etc.).

This project is positioned between low-level runtime libraries (like NINA.Core and NINA.Equipment) and the final application shell (NINA, NINA.Plugin).

The offline framing map uses a specialized pipeline within the Sky Survey subsystem to render celestial data:

• SkyMapSceneBuilder: Projects constellations, stars, DSO outlines, and grids into a per-viewport scene.
• SkyMapViewportProjection: Handles projection, panning boundaries, and overlays (telescope markers, camera overlays). It supports both Equatorial and Alt/Az modes.
• SkyMapRasterRenderer: Draws the scene into a reusable WPF WriteableBitmap. In software-only mode, it uses a 50% scratch bitmap for dragging to optimize performance.
• SkyMapAnnotator: Coalesces drag invalidations to a 60 Hz interval and manages the rendering of annotations.
• SkyMapObserverSnapshot: Provides the time/location boundary for coordinate conversion (Celestial $\leftrightarrow$ Alt/Az) and horizon clipping. It expires after one minute to ensure grids are rebuilt together.

The NINA.Image library follows a specific data flow to transform raw exposure data into renderable images and analyzed data. Developers should follow this sequence when integrating image processing:

1. Ingestion: Produce or load exposure data into an IExposureData implementation.
2. Conversion: Use ExposureDataFactory and ImageDataFactory to convert that data into IImageData.
3. Rendering: Use RenderedImage to turn IImageData into a WPF BitmapSource. This stage handles stretching, debayering, annotation, and thumbnail generation.
4. Analysis: Run StarDetection and related analysis classes to update StarDetectionAnalysis and image statistics.
5. Persistence: Use BaseImageData.FromFile and SaveToDiskAsync to route supported on-disk formats through the shared pipeline.

The NINA.Astrometry library has a narrow dependency footprint to maintain its status as a domain library. It only references:

• NINA.Core: Provides shared utilities, logging, and the database context.
• NINA.Profile: Provides location-dependent calculations via the IProfileService.

It has no dependency on UI projects, plugin loading systems, or device mediators.

Data access in this library follows a specific boundary pattern. While NINA.Astrometry contains the astronomy-specific queries, it does not own the entire data stack:

1. Schema/Config Types: Defined in NINA.Core.
2. Runtime SQL Files: Shipped by the main NINA executable project.
3. Astronomy Queries: Implemented within NINA.Astrometry via DatabaseInteraction using NINA.Core.Database.NINADbContext.