Files — The Rig's Image Archive

Every frame a sequence captures is written to the rig’s own disk as it happens, and so is every frame you shoot by hand on the Imaging screen (Quick Captures) — nothing depends on your phone, tablet, or browser staying connected. The Files screen is the browser for that archive: open it from the Home screen or the folder button on the Imaging screen to see every project on the rig, drill into a night’s frames, and inspect full FITS metadata.

It is one of two ways to reach the archive (Where Your Images Live): Files (this page) browses the rig’s disk, and Data Sync pulls the archive to the computer where you process.

How frames are organized

Frames land in a fixed, predictable tree:

<data directory>/
└── <Project>/
    └── <Target>/
        ├── LIGHT/
        │   ├── <Filter>/          e.g. Ha/, OIII/, or NoFilter/
        │   └── ...
        ├── DARK/                  reserved for calibration frames
        ├── FLAT/
        └── BIAS/

• Project is the name you give a sequence in the PROJECT field at the top of the Sequencing screen. Leave it blank and ARIS names it for you: the primary target plus the date, like M31 2026-07-19.
• Target folders come from the sequence’s target names.
• Filter folders always follow the sequence’s filter name — on a one-shot-color rig with no wheel, frames land in NoFilter/.

A project accumulates across nights: run the same project again next week and new frames join the same folders, with frame numbering continuing where it left off. The app groups a folder’s frames by night as you browse — a “night” runs noon to noon, so a 1 a.m. frame files under the evening it belongs to.

Filenames carry the metadata

Every file is self-describing, so the archive stays useful even when you copy frames off the rig by hand:

M31_Ha_300s_G100_O30_bin1_20260719_014512_0042.fits

That is target, filter, exposure, gain, offset, binning, local date, local time, and the frame number within that folder. Values the rig does not know are simply left out of the name rather than invented. Files you drop into the tree yourself (a stacked master from another tool, for instance) are listed as-is.

FITS headers, done properly

ARIS writes the same class of headers dedicated imaging suites write, so your frames drop straight into PixInsight, Siril, or any FITS-aware tool with nothing to fix up:

• Exposure and identity — frame type, exposure time, gain/offset, binning, camera, filter, target, capture timestamps (UTC and local, plus MJD).
• Pointing — RA/Dec in both decimal and sexagesimal form, altitude/azimuth and airmass at the exposure midpoint, pier side.
• Equipment — telescope, focal length and ratio, focuser position and temperature, rotator angle, filter wheel.
• Site and conditions — observer latitude/longitude, site elevation (when a GPS fix has provided it), and ambient conditions — temperature, dew point, cloud cover, wind — from the rig’s cached weather data when available.
• Guiding — how well that exposure was guided, measured over the exposure itself: the RMS in RA, in Dec and in total, the worst single guide error, all in arcseconds, and the number of guide samples (GUIDRMS, GUIDRMSR, GUIDRMSD, GUIDPEAK, GUIDNSMP, the keywords N.I.N.A. Polaris also writes). Light frames only, and only when PHD2 was guiding with a known image scale; otherwise the cards are left out, never written as zero.

One rule governs all of it: a value the rig does not know is omitted, never fabricated. Anything the camera driver already stamped is preserved untouched.

The calibration library

Darks, flats, and bias frames captured by sequence commands go to a shared Calibration project rather than any one target’s folder — organized by camera, then frame type, then filter. Calibration data is camera-scoped by nature, so the library is reusable across every project that camera shoots; matching works off the exposure, gain, temperature, and night recorded in each file.

Stacked results work the other way around: live-stack snapshots and overnight deep-stack masters land beside the subs they came from, in the target’s own folder.

Quick Captures

Frames you shoot by hand on the Imaging screen are kept too. The rig files them in the reserved Quick Captures project, under the target Untitled and the filter the wheel is on:

Quick Captures/Untitled/LIGHT/<Filter>/

• Singles and the Loop. A single frame from the shutter is kept when it lands, and so is every frame the Loop takes. The rig does the saving, so it does not matter whether the device that started it is still connected.
• Filed as it was shot. The filename and FITS header carry the exposure, gain, offset, and binning the capture used. The filter folder is the one the wheel is on — the name you gave that slot, if you named it — or NoFilter/ with no wheel.
• Focus frames are not kept. Frames the Focus screen takes are focusing aids. To keep one anyway, press Save to rig on the Imaging screen: it files the frame the camera is holding, the same way. Pressing Save to rig on a frame that is already kept files nothing new.
• Nothing is dropped. If the rig’s disk falls behind a fast Loop, the Loop waits for it rather than skip a frame. A single the disk cannot take in time is refused with a message before its exposure starts.
• Anything not kept is reported. If a frame could not be kept — say the camera replaced it before the rig could read it, or the write failed — you get a storage notification and the rig’s night journal records why.
• A few cameras keep less. A camera that cannot tell the rig which frame came from which exposure keeps Loop frames but not singles, and a camera that does not hand its frames to the rig (a Seestar) keeps neither. The app tells you once.

Note

On a NINA rig, NINA keeps them. The NINA plugin keeps no archive of its own, so there is no Quick Captures and these frames do not appear in Files. Instead a frame you shoot by hand on the Imaging screen — a single, or every frame of the Loop — is handed to NINA, which saves it into NINA’s own image folder the way it saves a snapshot taken in NINA: as a SNAPSHOT frame, named by NINA’s file pattern (both are set in NINA’s options). Like NINA’s own snapshots it carries the guiding RMS, in the file name if your pattern includes it, and its header carries the guiding cards listed above. Save to rig hands NINA the frame on screen, or, if NINA already saved it, tells you where. If NINA does not save a frame, you get a storage notification. On a NINA rig the Loop runs in the app, so it stops if the device that started it disconnects.

Browsing

The Files screen is a three-level drill-down:

1. Projects — a card per project with its size, night count, and a preview thumbnail, plus a disk-usage strip for the rig.
2. Frames — a night-grouped thumbnail gallery with chips to filter by target, frame type, and filter.
3. Viewer — tap any frame for a full preview with its complete FITS header panel.

Thumbnails are generated on the rig at capture time, so browsing stays fast even over a slow connection to a remote rig.

Managing the archive

• Rename a project from its card menu — the folder on disk is renamed with it.
• Select and delete frames or whole groups; the confirmation always shows the count and total size first. Data a running sequence is actively writing is protected from deletion and rename.
• Download selected frames to the device you are browsing from. For bulk transfer to your processing machine, Data Sync is the better tool.

Caution

Files shows the rig’s only copy of your data. Deleting here removes frames from the rig’s disk permanently — if you want a safety net, let Data Sync mirror the archive to your own computer first.

Disk protection

Storage guards itself so a full disk never costs you an unattended night silently:

• A sequence will not start when free space is already below the floor (5 GB by default).
• When free space falls below twice the floor mid-run, you get a low-disk warning and the night continues.
• If the floor itself is hit, the sequence aborts cleanly — the checkpoint is kept, every frame captured so far is safe on disk, and the run can resume into the same folders once space is freed.

Frames you shoot by hand follow the same rules. Below twice the floor they are still kept, and you get one low-disk warning each time free space drops that low. At the floor the Imaging screen will not start a Loop or take a single frame, and a running Loop stops and tells you why, rather than shoot frames the rig cannot keep.

Note

The rig is the source of truth: the archive lives on the rig’s disk and survives app restarts, browser refreshes, and network drops. Frames are written atomically, so a power cut mid-write never leaves a corrupt half-frame in the tree.