Apple MacOS - Astro Pixel Processor Forum

Setting "image viewer in separate window" prevents APP launch

Alfonso Caschili — Sat, 30 May 2026 08:51:02 +0000

Hi Mabula.

I encountered this bug in APP beta 45 running on macOS 26.5:

when setting "image viewer in separate window" in the config the application freezes with a beach ball. Force closing it and relaunching causes it to freeze immediately at launch so it becomes unusable.

This happened with beta 45. I tried to launch beta 38 (with the config set) but wouldn't launch either (expected as they share the same key).

After some spelunking I found that APP saves its config in `~/Library/Preferences/com.apple.java.util.prefs.plist`

I reset the key detach.imageviewer.mode to false manually and I'm able to restart the application.

The separate frames list works without issues.

Saved the hang report (attached).

From what I can tell the AppKit main thread is pinned 100% inside an infinite accessibility-tree recursion:
NSAccessibilityChildren → NSAccessibilityUnignoredChildren → NSAccessibilityChildren → …, bottoming out in
NSAccessibilityUnignoredChildrenForOnlyChild.

seems that the detached-viewer window builds an accessibility hierarchy with a cycle.

This, in my instance, causes the utility alt-tab to freeze the app as it inspects its accessibility chain.

Given that the frames list works fine maybe there's something that can be done in APP to prevent this?

10902

APP 2.0.0 beta43 is slow on normalization

Philippe BERNHARD — Mon, 04 May 2026 07:43:48 +0000

Hello

I am working on MBP M4Pro Max and if star analyser and registration is faster, normalization (non overlap) is very slow compare to past versions.

I preprocessed something close to 700 images R, G, B, S, H, O and normalization took a much longer time than before (maybe something close to 1-2 seconds per image. Before these last versions the time for 700 images was very fast (several seconds for all). Images have 100 Mpix (Moravian C5)

Anyway, there is something I don't understand in the reasonnement :

Why normaization reflect to the reference image ? As if a red image is reference, all S, H, O will be normaliezd along this red one ?

The real (or optional) procedure should have each stack get normalized with its own reference. Usually I find a green image to be set as reference. There are lot of stars and maybe some gradients or huge signal on it. If I take for example the OIII ones, signal is very low and I don't understant why it is normalized with the green reference.

Please explain if I am wrong

Best,

Philippe

APP 2.0.0-beta41 crashes with Sony A7 IV .ARW on macOS 26.4.1 — native crash in arm_libRawConverter (getRawData)

Gwen Cruise — Mon, 20 Apr 2026 01:49:55 +0000

Hi all,

Getting a reproducible hard crash in beta41 on my Sony A7 IV .ARW files. JVM aborts and the window just disappears. Wanted to flag it here in addition to the email I sent to support (with the .ips files attached).

Setup: macOS 26.4.1, Apple Silicon (MacBook Pro 18,3), APP 2.0.0-beta41 on GraalVM 24.0.1+9.1. Shot on Sony A7 IV, 14-bit ARW, ISO 8000, 4 s subs. 51 lights / 15 darks / 16 flats of comet C/2025 R3 (PanSTARRS).

What I've tried:

Full set (lights + darks + flats), defaults on 2) CALIBRATE → "create Masters & assign to Lights" → crash every time, 5-10 s in.
Lights-only (no darks/flats). Got past master generation / assign a couple of times, but then crashed at 3) ANALYSE STARS instead. Same signature.
RAM slider at default (512 MB) and at max — same crash either way, so it doesn't look memory-related.
Cmd+Q and relaunch between attempts.

Crash signature (from the .ips):

Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000008188
Triggered by Thread 75 (Java: pool-91-thread-1)
Crashing frame: arm_libRawConverter.jnilib Java_com_ariesproductions_rawConversion_LibRawConverter_getRawData + 344

The crash is in the native raw decoder (getRawData), and the fact that it also crashes at analyse-stars with lights-only lines up — star analysis re-reads each light through the same decoder. Looks like a null-pointer deref at a small struct offset (0x8188), which feels like a header/metadata parsing issue specific to these ARWs.

Anyone else seeing this? Happy to send sample .ARWs if it helps repro.

Thanks, Gwen

MacOS Tahoe compatibility

jochen scharmann — Thu, 05 Feb 2026 05:15:55 +0000

Does APP work on MacOS Tahoe (V26)

Mac Command key not working with latest update

C.S. Church — Fri, 14 Feb 2025 02:15:45 +0000

Oddly, in the latest update, the Apple Mac command key isn't working to select A (selecting all files for lights, flats, bias) in any particular target folder.

The key works outside of APP on my Mac normally.

Is there a setting I can click to correct this problem?

FITS Header for Extract HA or Extract OIII from OSC: DEC and RA

Jim Case — Thu, 30 Jan 2025 01:02:34 +0000

I have been using several dual narrowband OSC filters successfully with APP for some time, but am surprised that several FITS header fields are missing from the extract HA or Extract OIII stacks when these algorithms are used. In a normal OSC stacked integration I see that the RA, DEC, and pixel size information are included, but these header fields seem to be missing when I execute either the HA-OIII Extract HA or HA-OIII Extract OIII algorithms, as well as several other FITS fields. Is there an option to preserve these other header fields when one of the Extract HA or Extract OIII algorithms are used? Thanks.

APP exits without error message on macOS High Sierra

Peter Clark — Wed, 15 Jan 2025 17:39:24 +0000

I have a 2013 iMac 27 machine which I've installed the latest APP on. Apple no longer support this computer and the last runnable version of OSX is High Sierra.

When I try to run APP nothing happens ... there is no error message. Is there a minimum version of OSX it will run on ?

Best Regards

Peter Clark

APP taking a LONG time to load and then crashes on Sequoia 15.1.1

Phillip Hoppes — Sun, 01 Dec 2024 16:59:43 +0000

I have been running APP on my M2 MacStudio running Sequoia and it has been working fine. I updated to the latest version of Sequoia 15.1.1 and now APP takes forever to load and if/when it does if I load up some subs it starts but then crashes. All of my data resides on the internal SSD. I have 128Gb of Ram and 2Tb of free disk space. Resources should not be an issue. Sorry for the double post. I thought the first post did not work as I waited a while and it looked like the website had hung. This post has more info than my first.

APP Crashing on Sequoia 15.1.1

Phillip Hoppes — Sun, 01 Dec 2024 16:53:27 +0000

APP crashes and is not working on latest Apple M2 running Sequoia 15.1.1 It takes forever to load and use to load very fast. If/when it does load it either hangs or if I do get to load some subs it then crashes.

Java error with LNC

Cheetah — Tue, 26 Nov 2024 19:17:48 +0000

Out of the game for a few years. Coming back to find a very new and updated APP (...awesome!)

Anybody else getting an error like this when trying to use LNC:

10044

I'm able to integrate, but without this option.

Macbook Pro w/M2 processor running Sonoma. Tried updating Java...no luck, same error.