Skip to content

SlopCap 0.1.2

Latest
Latest

Choose a tag to compare

View all tags
@dmead dmead released this 03 Nov 03:44
· 6 commits to main since this release
v0.1.2
c184eb7

Downloads

File For
slopcap-windows-x64.zip (27.3 MB) Windows 10 / 11, 64-bit: slopcap.exe (the whole program in one file, camera drivers inside), a README and the guide (docs/)
slopcap-linux-x64.zip (64.5 MB) Linux x64, Ubuntu 26.04 or newer: Qt, the camera drivers and their udev rules inside, a launcher, a README and the guide
slopcap-macos-arm64.zip (44.9 MB) Mac with Apple silicon, macOS 27 or newer: SlopCap.app (Qt and the camera drivers inside), a README and the guide
SHA-256 
3902c59f3f99ef5c55fb7ffb35b8f5b8ee441bcf6f66d3e3a8d77ab9fb58233c  slopcap-linux-x64.zip
b0766637bf37f44aac3759624e81e6c3ac2e9ebdef339c5544ce1fb7afa528a0  slopcap-windows-x64.zip
7d4e15ef47990d778b0f0caab6f55730581f11f58efc72221026add1c710c864  slopcap-macos-arm64.zip

SlopCap is free software under the GNU General Public License, version 3. Each zip has LICENSE (SlopCap's) and
licenses/, with the licenses of everything else inside it.

SlopCap isn't signed. Windows warns about an unknown app the first time: More info, then Run anyway. On a Mac,
drag SlopCap.app to Applications and open it; macOS refuses it the first time, so go to System Settings → Privacy &
Security and choose Open Anyway.

What's new in 0.1.2

Much less CPU on Windows, a recording buffer that rides out disk stalls, and fixes to recording lengths and 16-bit
files.

Less CPU on Windows

SlopCap 0.1.1 used about one CPU core at every frame size on a small Windows PC with Intel graphics (Core i5-8500T),
where SharpCap used a fifth of one at 640×480. Two causes:

  • Intel's Windows OpenGL driver burns a core waiting for each screen refresh.
  • SlopCap redid its display work for every frame the camera delivered.

Measured on that PC with a ZWO ASI585MC, recording 30 s at each size, CPU in cores:

0.1.1 0.1.2 SharpCap 4.1
3840×2160, 8-bit 1.36 0.85 1.35
1920×1080 1.25 0.39 0.50
1024×768 1.16 0.28 0.30
640×480 1.14 0.28 0.20

(0.1.2's figures are from its release candidate before the last change below, which measured the same.)

What changed:

  • The preview no longer waits for the screen's refresh on Windows; it paces itself instead.
  • The display work (stretch, white balance, histograms) is done once per shown frame.
  • The preview shows 30 frames a second unless you pick 15, 60 or the screen's rate on its toolbar.
  • The window is redrawn once per shown frame, not again for each panel that changed in between. While the session
    driving these tests was watching the screen, the rest of the machine worked about 0.8 cores harder beside SlopCap
    than beside SharpCap; with this release that fell to under 0.1, most likely for this reason.
  • The live focus score runs 15 times a second off the Focus tab (every frame on it, and during sweeps).

Recordings keep every frame. Focus, collimation and the other tools still work as before.

Recording

  • A recording buffer sized for the format: about 8 seconds of frames, at most a quarter of the free memory (1 to
    4 GB). On a 16 GB PC that's about 450 MB at 640×480 and 2 GB at full frame, where 0.1.1 always took 1 GB. A
    filling SSD stalls for hundreds of milliseconds at a time: at full frame the old 1 GB lost frames to those stalls,
    and this one lost none until the SSD was nearly full (when no buffer keeps up).
  • A warning before frames are lost: the bottom bar's buffer figure turns orange, then red, as the disk falls
    behind, and SlopCap says so.
  • Recording lengths are the capture's own. "Saved N frames (X s)", the .txt file's duration and end, and the
    mid-recording time in the file name (WinJUPOS) used to include the time the disk took to catch up after the camera
    stopped. A 30 s full-frame recording said 36 s and was named up to 3 s late.
  • 16-bit SER files say 16 bits. The values were always stored in the top bits of each 16 (a 12-bit camera's
    4095 as 65520), but the header said 12, which some programs read as values running to 4095 only. The .txt file now
    gives the camera's own depth (ADCBits=12). Older 16-bit recordings still say 12; SlopCap's own replay reads both
    kinds correctly.
  • The session log gives each recording's CPU use, buffer size and drain time.

Fixes found by running every test on Windows

  • Reading a recording that was still being written failed on Windows: the file size came from the directory, which
    Windows doesn't update while the file is open.
  • The session log's output wasn't flushed, so a program reading it on Windows saw nothing until SlopCap quit.

Cameras and mounts

As in 0.1.1: ZWO, QHY, Player One, ToupTek and MallinCam cameras, with each vendor's driver inside; mounts through
INDI or SlopCap's own drivers (LX200 and OnStep, Celestron NexStar, Sky-Watcher SynScan and direct, the SynScan app).

Not yet tried on real hardware

  • Player One, ToupTek and MallinCam cameras (tested against simulations of their SDKs)
  • the built-in mount drivers (tested against simulations of each protocol)
  • the Mac app on a screen
  • these CPU changes on a Mac or Linux PC with a camera; they were measured on Windows, and the tests pass everywhere
Assets 5
Loading