> ## Content Index
> Fetch the complete content index at: https://macobservatory.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Strata 1.2.1: How One Tester's Logs Cut a 19-Hour Solar Batch to Five
- URL: https://macobservatory.com/strata-1-2-1-solar-batch-performance-drizzle/
- Published: 2026-08-21T17:28:04.000Z
- Updated: 2026-08-21T17:28:04.000Z
- Description: Sven ran the same 1,999 solar videos through Strata and Planetary System Stacker on the same Mac. Strata took 19.65 hours. PSS took 7.2. His logs found a GPU bug that was invisible on my own hardware.
- Author: Andrew Burwell
- Tags: Software, #planetary, #processing, #mac-native, #workflow

Strata is my native macOS stacking and sharpening app for planetary, lunar and solar captures, and until this week it was too slow for high-volume solar work. Sven Kohle, a solar imager in Germany who runs a daily program and had been using Planetary System Stacker for years, ran the same 1,999 Ca-K videos through both on the same Mac and the same drive. Strata took 19.65 hours. PSS took 7.2\. He told me the speed was what kept him from switching. Version 1.2.1 runs that same night in 4 hours 59 minutes, and it took his logs to find the reason.

![Two-panel comic showing a Bavarian astronomer at a solar telescope and a developer at a Mac on a Florida beach, connected by a transatlantic cable, both reacting to Strata's processing speed](https://storage.ghost.io/c/8d/3a/8d3ae6c9-185e-49c7-b8a6-36d44545d9f9/content/images/2026/08/image.jpg)

Sven's review of 1.2.1 arrived as a comic. It was hilarious to get this in my inbox.

He captures Ca-K and hydrogen-alpha in parallel through most of a clear day, carries the night home on a direct-attached array, and processes while he sleeps. A session can run to 20 TB. One SER file is about 3 GB and there are two thousand of them. Software that can't get through the pile before the next clear day is no use to him regardless of how good the output looks.

## What his logs showed

Rather than benchmark anything, I asked for the logs from both programs and he sent all of them. Every number here is summed from real timing lines across all 1,999 files: 524,447 frames, 3400x3400 8-bit mono, a median of 262 frames per file, roughly 6 TB for the night, one M1 Mac, one drive.

The first thing the decomposition settled was his original question, which was whether something had gone wrong. Nothing had. Throughput held steady for twenty hours and all 1,999 files succeeded. One phase was consuming the GPU and the rest of the pipeline was waiting behind it.

Measured from the batch log

Where 19.65 hours went

1,999 files, 524,447 frames, 3400x3400 mono, one M1 Mac.

Quality analysis (GPU) **13.72 h** 70% 

A constant 10.6 frames per second for twenty hours.

Normalize Capture **2.29 h** 12% 

Re-reading about 240 frames per file that analysis had just read.

Stacking **2.30 h** 12% 

4.1 seconds per file across two thousand files.

Reference, AP grid, selection **1.07 h** 5% 

Export and housekeeping **0.28 h** 1.4% 

0.1 to 0.2 seconds per file, zero stalls, zero failures.

Quality analysis took 13.72 of the 19.65 hours, running at a constant 10.6 frames per second. Normalize Capture took another 2.29, and it spent that time re-reading about 240 frames per file that analysis had streamed through the GPU moments earlier. Early in the night the page cache hid that cost. Once the night grew past what the cache could hold, the cost went up fivefold. Stacking, the part most people assume is expensive, took 2.30 hours across two thousand files. Export took 0.28 hours in total.

## The comparison nobody expected

Then the per-file numbers arrived and inverted the question.

Planetary System Stacker 0.9.8

- **Time to process:** 7.2 hours
- **Per file:** 93.3 s mean (56 to 155)
- **Concurrency:** about 7 files at once
- 51.8 summed CPU-hours packed into 7.2 hours total
- Multi-core CPU, Python, free and open source
- 17 s per file just to save the result

Strata, the 19.65 hour run

- **Time to process:** 19.65 hours
- **Per file:** 35.4 s mean (31.9 median, 51.8 max)
- **Concurrency:** strictly one file at a time
- 2.6x faster per file, twelve hours later to finish
- Metal GPU, native macOS
- 0.1 to 0.2 s per file to save

Planetary System Stacker is Rolf Hempel's free, GPLv3 lucky-imaging stacker for moon, sun and planets, written in Python and installable on macOS through PyPI or through [Nick Kohrn's one-click launcher](https://macobservatory.com/planetary-system-stacker-now-has-a-launcher-installer/). It is the reference much of Strata's pipeline was validated against and it is good software.

It also lost per file by a wide margin. PSS averaged 93.3 seconds a file. Strata averaged 35.4\. Strata was already 2.6 times faster at the actual work and still finished twelve hours later, because PSS starts a new file roughly every twelve seconds and keeps about seven of them in flight across CPU cores. It packed 51.8 summed CPU-hours into 7.2 hours of total time. Strata does everything on the GPU, one file at a time, so a single phase that saturates the GPU sets the pace for the whole night. PSS's 7.2 hours was a good number that came out of a sound design decision.

## The bug that was invisible on my machine

Sven's diagnostic log put the quality kernels at 86.5 milliseconds per frame. On my machine (an M3 Ultra) the same kernels wait about half a millisecond. Same code, same file, two orders of magnitude apart.

The four quality-metric kernels each ended with three atomic adds per thread, all landing on the same three memory addresses. That is roughly 3.9 million serialized read-modify-write operations for every 3400x3400 frame. What that costs depends on the GPU generation, and my M3 Ultra absorbs it almost for free. His M1 does not. I could have profiled my own hardware for a year and never found it.

What changed in 1.2.1

Three fixes, identical output

Nothing about what Strata measures changed. Only how the work is scheduled and read.

Atomic contention removed

Threadgroup reduction replaced millions of same-address atomic adds. 86.5 ms per frame down to under 1 ms on the reporting hardware.

Each file is read once

Normalize now takes its measurements during analysis's single pass instead of re-reading 240 frames per file. About two hours back on a 6 TB night.

The disk never sits idle

The next file loads while the current one stacks and exports, one file deep so memory stays flat. A 24-file batch ran about a third faster here.

Side effect: determinism

Scheduler-ordered atomics were never reproducible. Identical inputs now produce bit-identical quality scores and frame rankings.

The kernels now reduce inside each threadgroup and a second small kernel folds the partial sums in a fixed order. Nothing about what gets measured changed, which matters because the frame quality metric is the part of Strata I am least willing to touch. Normalize Capture now takes its measurements during the single pass analysis already makes, so each file is read once. And while one file finishes its stack, sharpen and export, the batch reads and analyzes the next one in the background, one file deep so memory stays flat. That last change on its own made a 24-file batch about a third faster on my Mac.

## Now the disk is the limit

He ran the whole night again on 1.2.1\. The first pass finished in 6 hours 7 minutes, with 1,998 of 1,999 files through and one failure he traced to an accidental profile that had frame rejection switched off. The corrected rerun the next evening took **4 hours 59 minutes for all 1,999 files with zero failures**, using Normalize Capture and his preferred 32 pixel alignment grid. Against 19.65 hours on the same files and the same hardware.

> I am so impressed. Real time DAS processing with max Warp-Speed, GPU could do even more with faster disks. This is fantastic. The Strata-Flux-Capacitor.

![](https://storage.ghost.io/c/8d/3a/8d3ae6c9-185e-49c7-b8a6-36d44545d9f9/content/images/2026/08/strata_batch_video_processing_progress.png)

His IO monitor is the more interesting screenshot. The array sustained about 396 MB/s of reads, and he wrote that the GPU could do more with faster disks. He is right, and that is the limit now. Six terabytes at 396 MB/s takes about 4.2 hours to read, and the run finished in 4 hours 59 minutes. Roughly 84 percent of the night is the drive handing over bytes. Per file that is about 7.6 seconds of reading inside a 9 second file.

![](https://storage.ghost.io/c/8d/3a/8d3ae6c9-185e-49c7-b8a6-36d44545d9f9/content/images/2026/08/disk_io_stats_data_read_write.png)

Which means the remaining lever is his storage rather than my code. Faster storage should take most of that 4.2 hours out, and I am not going to put a number on it until someone measures one. If you have a fast NVMe volume and a few thousand SER files, that is the experiment I want to see.

Partner

Agena AstroProducts

Telescopes, cameras, mounts, and accessories from the brands that matter.

ZWO · Celestron · Sky-Watcher · Explore Scientific · William Optics

[Shop Agena Astro](https://agenaastro.com/?rfsn=7382607.4cfa63&ref=macobservatory.com) 

Mac Observatory earns a commission

[ ![Agena AstroProducts](https://storage.ghost.io/c/8d/3a/8d3ae6c9-185e-49c7-b8a6-36d44545d9f9/content/images/2026/03/agena-astro-banner.webp) ](https://agenaastro.com/?rfsn=7382607.4cfa63&ref=macobservatory.com) 

## What this means if you image the Sun every day

Throughput is the entry ticket for this kind of work rather than the point of it. The point is what you can do with two thousand files a day across a season.

Two things in 1.2.1 matter more than the time for that. The corrected run put all 1,999 files through with no stalls and no failures, so the batch can be left alone overnight. And the kernel fix made quality scores deterministic. The old atomic adds accumulated in whatever order the GPU scheduler chose, so two runs of identical code on an identical file could differ in the last decimal places, and frame rankings could shift between runs. They cannot now. Identical inputs produce bit-identical rankings.

0:00 

/0:27 

1× 

This is the output of 2000 recorded SER videos from Sven recombined into a timelapse. Check out the flares on the sun spots.

For anyone building a Ca-K time series across months, that matters more than the speed. If your selection of the best 40 percent of frames has to mean the same thing in November as it did in August, reproducibility is a requirement rather than a nicety. It arrived as a side effect of a performance fix.

The SER Utility that shipped alongside it serves the same kind of work. Point it at any capture and it reports header consistency, frame-count truth and timestamp integrity in about a second without importing the file, and it writes a repaired copy when a capture session crashed mid-file. A monitoring program generates thousands of files that can never be re-shot.

## Drizzle, and what the word has come to mean

The other half of 1.2.1 is that Strata's drizzle is now actually drizzle.

Drizzle is a specific algorithm from Fruchter and Hook's 2002 paper, built for the Hubble Deep Field. When a camera undersamples the optics, many slightly shifted frames collectively hold finer detail than any single frame can carry. You shrink each input pixel to a smaller drop and place it on a finer output grid, distributing its flux by exact geometric overlap. Planetary and solar work gets the dither for free, because seeing shifts every frame anyway.

What ships under the name in this corner of the hobby is usually interpolated upscaling. I can say that with certainty about two implementations: PSS, whose source is open and uses a bilinear upscale with integer shifts, and Strata's own previous version, which was the same approach. Elsewhere it varies. Siril implements genuine drizzle with documented droplets for deep-sky work. AutoStakkert describes its own as Variable Pixel Linear Reconstruction, which is the formal name of the real algorithm, and it is closed source so I have no basis to say more than that.

The more useful thing I found is that the field largely decided drizzle does not matter here, and for a good reason. Planetary imagers deliberately oversample. AutoStakkert's own site says most planetary recordings have little to gain from drizzling, the standard advice on Cloudy Nights is the same, and at 0.1 arcseconds per pixel on Jupiter that advice is correct. There is nothing below Nyquist to recover, and the usual recommendation to shoot at longer focal length instead is the right one.

Full-disk solar is the case where that advice fails, because you cannot add focal length when the requirement is the whole disk in one frame.

The test, in physical units

The recovery band, bounded at both ends

Lunt LS60MT at f/7, 420 mm, Player One Apollo-M Mini, 4.5 micron pixels, hydrogen-alpha at 656 nm.

2.218 arcsec/px

Pixel scale, from the Sun's own 944.3 arcsec radius against a 425.8 px fitted limb

\~2x

Undersampled against what a 60 mm aperture resolves

Spatial frequency, cycles per arcsecond

native stack

recovery band

beyond optics

0

0.225  
native Nyquist

0.443  
diffraction cutoff

The drizzled stacks carry signal inside the band, and the recovered spectrum dies at the cutoff. 2x and 3x agree within 10 percent in-band. All four scale factors agree within 3 percent below native Nyquist, so photometry is preserved. The band holds about half a percent of the image's structural power, which is why it is invisible to the eye and exactly what wavelet sharpening amplifies. 

So I measured it on my own capture. [Lunt LS60MT](https://agenaastro.com/solar-telescope-lunt-telescopes-60mm-ha-b600-ls60mt-standard-kit.html?rfsn=7382607.4cfa63&ref=macobservatory.com) at native f/7, 420 mm, a Player One Apollo-M Mini with 4.5 micron pixels, captured in Laminar. The Sun calibrates the analysis by itself. Its disk was 944.3 arcseconds in radius that day and the fitted limb in my image is 425.8 pixels, so the scale is 2.218 arcseconds per pixel, about 2x undersampled against what a 60 mm aperture resolves. No metadata required.

That gives a band with a hard edge at each end. Below 0.225 cycles per arcsecond is detail the native stack can represent on its own. Above 0.443 is detail a 60 mm aperture cannot resolve at 656 nanometres. Anything real in between had to come out of the dithered frames. The drizzled stacks carry signal there, and the recovered spectrum rolls off and dies at 0.443, where the optics say it must. Neither sensor noise nor an interpolation kernel has any knowledge of aperture diameter, which is what makes the termination point the useful test. The 2x and 3x stacks agree within 10 percent inside the band, which a fabricating process would not do, and all four scale factors agree within 3 percent below native Nyquist, so the photometry survived.

The band holds about half a percent of the image's structural power, which is why comparing two sharpened results by eye tells you nothing. It is also why it matters, because wavelet sharpening amplifies that band specifically. On a drizzled stack there is real signal there to amplify. On a native stack at those scales there is not.

Sven then ran the whole thing at production scale. His entire 1,999-file night at 2x drizzle finished in under five hours, materially the same as undrizzled, and he judged the results more crispy. His own rig is modestly undersampled too, at 0.69 arcseconds per pixel against a diffraction limit near 0.97 at the Ca-K wavelength, so there is real detail there for him to recover. He also pointed out something worth passing on: the Dawes limit that gets quoted everywhere is wavelength-independent, so it overstates the cutoff at 393 nanometres. Calcium K resolves finer than Dawes suggests.

The test is repeatable against any stacker, mine included: measure the radial power spectrum in physical units, find the band between the native stack's Nyquist limit and the aperture's diffraction cutoff, and check whether anything real lives there and stops in the right place. I am writing that method up separately so anyone can run it.

## Proof out in the wild...

I posted the drizzled result to the Cloudy Nights solar forum without mentioning any of the above.

![](https://storage.ghost.io/c/8d/3a/8d3ae6c9-185e-49c7-b8a6-36d44545d9f9/content/images/2026/08/Sun_2026-06-28-181610.jpg)

Warren (rigel123) assumed he was looking at a double-stacked Lunt, said the etalon tuning looked correct, and pulled the image into an editor to un-invert it. Gary (gstrumol) caught a typo in my date, then inverted and grayscaled the image and compared the disk against GONG for the correct day, reporting the match as good and consistent with a single-stacked LS60\. Dan (mintakaX) downloaded it, de-colorized it and was happy with the result.

Three experienced solar imagers took a drizzled Strata output apart and it held up, and one of them read the disk as coming from a scope with twice the etalon stack. [The thread is here.](https://www.cloudynights.com/forums/topic/1008200-solar-detail-full-disk-6282026-lunt-60/?ref=macobservatory.com)

Frequently Asked Questions

Common questions about batch solar processing and drizzle on the Mac.

Is Strata faster than PSS or AutoStakkert on a Mac?+ 

On the one workload measured in detail, a 1,999-file solar batch on an M1 Mac, Strata 1.2.1 finished in 4 hours 59 minutes against Planetary System Stacker's 7.2 hours on the identical files, and Strata was already 2.6 times faster per file before the 1.2.1 work. That is one machine and one dataset, not a universal multiplier. AutoStakkert is Windows-only, so it isn't a comparison Mac Observatory can make on the same hardware.

Will drizzle actually help my planetary images?+ 

Only if your capture is undersampled, meaning your image scale is coarser than about half your seeing-limited resolution. Most planetary imagers deliberately oversample at 0.1 to 0.25 arcseconds per pixel, and for them drizzle has nothing to recover. Full-disk solar and lunar work at 2 arcseconds per pixel or coarser is the case where it pays off, because you cannot add focal length without losing the whole disk. Worth knowing if you are checking your own sampling: the Dawes limit does not account for wavelength, so it overstates the cutoff at Calcium K.

What's the difference between drizzle and just upscaling the stack?+ 

Upscaling interpolates between the pixels you already have, so it produces a larger, smoother image with no additional information. Drizzle, the algorithm from Fruchter and Hook's 2002 Hubble paper, places each input pixel's flux onto a finer grid by exact geometric overlap across many dithered frames, which can recover detail the native pixel grid cannot represent. Several tools use the word for the first thing. Strata 1.2.1 does the second.

Does drizzle slow a large batch down?+ 

Not meaningfully, at least on the one large batch measured. A 1,999-file solar night run at 2x drizzle finished in under five hours on an M1 Mac, materially the same as the same night without drizzle. On large batches the drive is usually the limiting factor rather than the GPU, and drizzle does not change how much data has to be read.

Do I need a fast SSD to process thousands of SER files?+ 

It is the main thing left that would help. Since Strata 1.2.1 reads each file once and analyzes the next file while the current one stacks, storage throughput is the limiting factor on large batches rather than the GPU. On the 1,999-file night measured here, the drive sustained about 396 MB/s, so simply reading the roughly 6 TB of source video accounted for about 4.2 of the 4 hours 59 minutes the whole run took. Faster storage should remove most of that, though Mac Observatory has not yet measured an NVMe run to say how much.

Are Strata's frame quality scores repeatable between runs?+ 

They are as of 1.2.1\. Earlier builds accumulated quality metrics with GPU atomic operations whose ordering depended on the scheduler, so two runs of identical code on an identical file could differ in the last decimal places and frame rankings could shift. Identical inputs now produce bit-identical scores, which matters for anyone building a time series where frame selection has to mean the same thing months apart.

Is Strata good for someone just starting in solar imaging?+ 

Yes, and the batch machinery discussed here is not something a beginner has to touch. A single SER file goes straight into the pipeline and the defaults handle stacking and sharpening. Deep-sky imaging is a permanent non-goal, so this is the wrong tool for nebulae and galaxies. Mac Observatory keeps a full directory of Mac astronomy software for that side of the hobby.

Strata 1.2.1 requires macOS 14.6 or later and is on the Mac App Store now. If you run solar batches in the hundreds or thousands, I want your logs. That is twice now that a night of someone else's real data has found something I could not have found alone.

Mac observatory

One native pipeline for planetary, lunar and solar

Import, analyze, stack, derotate, sharpen, color and export in one window on the Mac.

[Strata →](https://macobservatory.com/strata-planetary-processing) [Mac Astronomy Software →](https://macobservatory.com/mac-astronomy-software) [PSS on the Mac →](https://macobservatory.com/planetary-system-stacker-now-has-a-launcher-installer/) 

Astrophotography from the Mac perspective