Strata 1.2.1: How One Tester's Logs Cut a 19-Hour Solar Batch to Five

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.

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.

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 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. 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.

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.

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.

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

Mac Observatory earns a commission

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.

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.

So I measured it on my own capture. Lunt LS60MT 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.

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.

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.