Astro Pixel Processor Forum - Recent Topics

Issue in beta 44 with mosiac registration

Christian Gow — Sat, 16 May 2026 04:45:01 +0000

I am currently running the new Beta 44 and having issues with correct mosiac registration.

DDC is on. Even with quick projection preview it does not show up correctly. Registration mode is mosaic, registration model is projective.

I have tried default stars 500, 1000 and now 3000 (300 gives the closest result).

Any insight? I have not had this type of mosaic issues in the past few years so bit of a suprise.

10893

Stacking Different Focal Lengths

Frank Coster — Sat, 16 May 2026 00:15:29 +0000

I often image the same object simultaneously using both of my OTA's. Same location and time. Both are high end refractors with identical cameras, (2600mm pro) and filters (Antlia). One is 930mm Fl and the other is 560mm Fl.

I've been stacking them in APP for a few years now and am generally pleased with the results, especially with APP 2.0 beta44. I have heard some pushback online that two focal lenghts can cause softness and artifacts. Can anyone offer any tips, tricks or cheat sheet that might offset me wondering if that might be true?

Again, I am pretty happy with my current workflow and results, but I'm always looking to improve. I have noticed a lot of impovement over that last year with APP, so a big shout out and thanks to Mabula!

Thank you for any feedback,

Frank

VdB 15

Paolo Banci — Tue, 12 May 2026 21:00:49 +0000

10891

Remote data from China.

Static Working Directory

Reginald Pratt — Tue, 12 May 2026 16:45:07 +0000

It would be great if the working directory didn't change based on the last files loaded. I (and probably many others) keep their master calibration frames in a different location than the light frames. As it is now, I open APP and set my working directly to where my lights are and load them. Then I load my calibration frames but before I can initiate the process I have to go back and reset my working directory so that the resulting files save to the correct location. Yes I could copy my calibration frames to be in the same place as the lights but that seems like an unnecessary step when the working directory could just be static.

Love APP and the work you're all doing just wanted to get some feedback!

Problem with Integration

Allen Lloyd — Tue, 12 May 2026 10:51:00 +0000

I am using version 2.0.0-beta43 (2.0.0-beta43). I had no problem integrating files, yesterday.

Today, I am getting the warning (attached screenshot). I have not changed any of the integration settings. What has suddenly gone wrong?

If I click OK, the programme proceeds at a snail pace.

Please help.

10890

Images that won't get registered by APP (any version)

Walter Leonhard Schramböck — Fri, 08 May 2026 15:15:29 +0000

I have problem registering my images when the FOV is very small with a very small number of stars and these are sometimes very big. This kind of subframes are generated by my old Meade 10" SC scope in combination with a small sensor.
I think I tried everything but APP does reject at least the blue channel while registering. Additional to the above conditions there was full moon in the sky, so SNR is bad.
Pixinsight also does not register these images, SIRIL the same. Only Setiastrosuite does, but this one does introduce other problems to the image.

Is there a chance to implement a mode for such kind of bad images, so that i can actually make use of them?

Thank you!

I attached one uncalibrated subframe from the blue channel to show what I am talking about.

10886

Astro Pixel Processor 2.0.0-beta45 release notes - Work In Progress

Mabula-Admin — Tue, 05 May 2026 10:17:34 +0000

Astro Pixel Processor 2.0.0-beta45 release notes

FIXED 4)REGISTER comet/one-star
As reported here https://www.astropixelprocessor.com/community/comet-registration-and-integration/beta-41-comet-registration-issues/#post-34307 the comet/one-star regisgtration mode had several issues with data that has little stars and low quality (shot in the morning glow). We have fixed 4 problems so now the data can be properly processed. We have fixed 2 bugs related to little stars so the images might not be able to register on the stars. We fixed the counter of which image is being processed in the comet mode and we also added a warning message if star registration is simply not possible and the user should try to disable star analysis and the register on the comet only.

Enhance AAD to remove more green and provide a balanced RGB output

Skye Goodrich — Mon, 04 May 2026 19:10:39 +0000

I like using AAD, but its still doesn't take into account (enough) the 2 G in the standard Bayer matrix, and bring it under control, tried 3 cameras on it and all leave green tinge, this due to matrix brings in so much green, the debayer algorithm needs to realize there's twice as much green coming into the sensors to normalize this and get it under control with the goal to balance R/ G/ B. I know when you write the algorithm, you like Green, because its like a luminance channel, but in the final output, suggest you AVERAGE or half the green, like someone get it under control so the final output has better white balance and all R/ G/B match in frames/ intensity like mono. I don't want to have to heavily fix this in post, and i want to come out right to start with.

Running SuperPixel vs AAD, the former has much blacker background and whiter objects (this proves the issue is with the algorithm), however I want the full resolution. Maybe we can try AHD or VNG to see how they look, or better yet, a revision on AAD like AAD2.

Encountered error in module CreateQualityRegistrationDescriptorsTask

Manoj Venkata Aditya Vempati — Mon, 04 May 2026 12:11:19 +0000

I am using beta44 to stack more than 2000 Seestar subframes and encountered this memory issue. What could be the reason?

10881

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