<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Astro Pixel Processor Forum - Recent Topics				            </title>
            <link>https://www.astropixelprocessor.com/community/</link>
            <description>Astro Pixel Processor Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 10 Apr 2026 17:31:32 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Beta40: Problem/Error/Warning when using LNC</title>
                        <link>https://www.astropixelprocessor.com/community/main-forum/beta40-problem-error-warning-when-using-lnc/</link>
                        <pubDate>Fri, 10 Apr 2026 13:19:02 +0000</pubDate>
                        <description><![CDATA[Hi all,
I just playing around with the new beta40. Seems to be quite fast. BUT I have encountered one problem:
&nbsp;
When integrating 460 lights from Horsehead (using two different focal...]]></description>
                        <content:encoded><![CDATA[<p>Hi all,</p>
<p>I just playing around with the new beta40. Seems to be quite fast. BUT I have encountered one problem:</p>
<p>&nbsp;</p>
<p>When integrating 460 lights from Horsehead (using two different focal length 1500mm and 1150mm with my 12" Newtonian) I tried first a standard integration, no problem. Then switched from Integrate mode "interpolation" to Bayer/X-Trans", scale 1.0, droplet 0.85: worked again with no problem.</p>
<p>&nbsp;</p>
<p>Then I thought try the new LNC: used 1st degree LNC with 3 iterations. Then everything went fine until "creating FITS HEADER": a "warning" poped up: encountered an Exception while saving..." (see attached image)</p>
<p>&nbsp;</p>
<p>So maybe a bug?</p>
10766
<p>&nbsp;</p>]]></content:encoded>
						                            <category domain="https://www.astropixelprocessor.com/community/"></category>                        <dc:creator>JuergenN</dc:creator>
                        <guid isPermaLink="true">https://www.astropixelprocessor.com/community/main-forum/beta40-problem-error-warning-when-using-lnc/</guid>
                    </item>
				                    <item>
                        <title>Astro Pixel Processor 2.0.0-beta40 release notes</title>
                        <link>https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-2-0-0-beta40-release-notes/</link>
                        <pubDate>Thu, 09 Apr 2026 20:35:53 +0000</pubDate>
                        <description><![CDATA[Astro Pixel Processor 2.0.0-beta40 release notes
Finally! The release is out, the improvements in this version over 2.0.0-beta39 and earlier are very significant, we have worked several mon...]]></description>
                        <content:encoded><![CDATA[<p><span>Astro Pixel Processor 2.0.0-beta40 release notes</span></p>
<p>Finally! The release is out, the improvements in this version over 2.0.0-beta39 and earlier are very significant, we have worked several months on this release to get everything ready for 2.0.0.</p>
<p>To summarize: <strong>2.0.0-beta40 is roughly 1.5 faster than 2.0.0-beta39 from calibration to integration for regular stacks with calibration data, tested on all platfroms, macOS, Linux and Windows</strong>. <strong>For mosaics, the results will be much better than that</strong>! To calculate a 100 panel mosaic, which is 2 GigaPixel large, it took 6-7 hours on a macbook Pro M4  with beta39. Beta40 completed it successfully in 1,5 hour. This illustrates how much faster the registration is in beta40 with the implemented optimizations. <strong>LNC 2.0 and LN 2.0 outlier rejection</strong> are introduced as big functional improvements. Many bugs were solved, especially for <strong>Linux distributions that use Wayland instead of X11</strong>.</p>
<p>&nbsp;</p>
<ul>
<li><strong>UPDATED DEVELOPMENT ENVIRONMENT TO Oracle JDK 25.0.2</strong>
<p>We have upgraded our development environment from <strong>Oracle Graal 24.0.1</strong> to <strong>Oracle 25.0.2</strong>. We will no longer use the Graal modified JDK because it will no longer support older macOS computers with Intel hardware. The update to Oracle 25.0.2 has a positive impact on performance again and it<strong> fixes many issues on Linux with the XWayland display server</strong>.</p>
</li>
<li><strong>WINDOWS INSTALLER FIXED</strong>
<p>2.0.0-beta39 and earlier had a problem in the windows installer. If you did not completely remove the older APP version, before installing 2.0.0-beta39, APP would not start. This issue was caused by changes in our code and how APP needs to be started. APP is now a fully modular java application and it can no longer be run using the old java way like java -jar astropixelprocessor.jar. APP 2.0.0-beta40 can now safely be installed over an older installation and you don't need to uninstall APP first.</p>
</li>
<li><strong>Local Normalization Correction 2.0 is here ! </strong>finally, a much improved and better version of Local Normalization Correction has been implemented. This version has 1st, 2nd and 4th degree variants and you can still set the number of iterations. The higher degrees (6th, 8th) variants are no longer needed. This version is much better in many ways. The solutions are much more stable to keep the resulting sky background flat. The old LNC algorithms were very unstable in this regard. The calculations will need much less memory and they will converge much faster to a good stable solution, so you will need less iterations to get a better correction of your images. The actual calculations in general have been much optimized, so the calculations complete much faster and are 75% multi-threaded now. The overall corrections with LNC 2.0 are much better on a wide variety of datasets, especially with stacks with more images or very bright objects on the mosaic seams, LNC1 was very bad at that. You can easily use LNC2 1st degree to normalize a normal stack and quickly remove all linear gradients present now from all subs while integrating.</li>
</ul>
<p>&nbsp;</p>
<ul>
<li><strong>macOS CMD+A to select all files in the native file chooser works now ! </strong>All the mac users will be very happy with this, including myself ! APP has been using Native File Choosers (this means, the same file chooser as the Operating System uses) for some time now. But we implemented this using a third party: javaFX and the way it was implemented was not great. It created a few minor and major problems. To solve the above Linux issue which is major, we have removed JavaFX completely from our project and that removed also a couple of minor issues that we had on our issue list. To still provide native File Choosers, we moved to another 3rd party library which has implemented it better clearly. The File Choosers should work better and faster now and the file chooser windows can now better be resized in all directions, this was a minor issue with the JavaFX implementation.  And fortunately, CMD-A in the macOS file chooser to select all files works now,  we have contacted upstream to ask for this if it is possible at all: https://github.com/JFormDesigner/FlatLaf/issues/1084.</li>
</ul>
<p>&nbsp;</p>
<ul>
<li><strong>Linux, much better support for new Linux distributions that run Wayland instead of X11, </strong>several issues related to Wayland have been solved. APP works as expected now on Wayland.</li>
</ul>
<p>&nbsp;</p>
<ul>
<li><strong>Local Normalization 2.0 outlier rejection is here ! </strong>It now uses corrections for both lokation and scale locally to adjust pixels stacks to find and remove outliers. Because scale is now also used, outliers are removed even better from images with low relative dispersion locally, and signal is better preserved from images with high relative dispersion locally. In general, it thus gives better outlier rejection and better Signal to Noise ratio in the resulting integrations.</li>
</ul>
<p>&nbsp;</p>
<ul>
<li><strong>IMPROVED, JavaFX dependency has been completely removed from APP</strong>
<p>We were able to completely remove javaFX as a dependency from our project. The dependency was needed earlier for support for native file choosers, but by doing so, it created several other problems of which one was critical for Linux distributions with XWayland display server. By removing this dependency, the application has also reduced a bit in size and performs now better and more stable in many situations.</p>
</li>
</ul>
<p>&nbsp;</p>
<ul>
<li><strong>Code optimizations !!!</strong> : We have worked extensively to optimize many critical modules in APP, some modules have been rewritten from scratch. The result is that APP is much faster in all modules from 2) Calibrate to 6) Integrate. For all optimizations, we have written tests to ensure that the results are the same or better than before. The following bulletpoints below here summarize all the optimizations:</li>
<li><strong>Whole New image alignment engine with </strong></li>
<li><strong>rewritten image resample/interpolation module (3-4x faster) and </strong></li>
<li><strong>rewritten drizzle image reconstruction (4-5x faster) </strong>the gaussian kernel is now the default kernel because it gives by far the best results with the new engine.</li>
<li>and the<strong> Coordinate Transformation factory</strong> for alignment of images with resampling (inverse) and drizzle (forward) is much improved and way faster.</li>
<li><strong>Projections are greatly optimized,</strong> all projections like <strong>Stereographic, Mercator, Equirectangular, Hammer-Aitiff work much faster now</strong>.</li>
<li><strong>Star analysis, removed many memory consumption problems/leaks</strong>, calculation of a flat luminance for the actual star detection is way faster !</li>
<li><strong>BPM creation ! Much faster 10x</strong> for hot pixel detection from darks</li>
<li><strong>improved overall concurrency implementation using java's virtual threads</strong> for non-blocking code while waiting on cpu intensive tasks and less heavy thread/worker instances</li>
<li><strong>Analyse flats</strong> is faster because of improved statistics, see below.</li>
<li><strong>Registration, dynamic distortion correction is more optimized and thus faster.</strong></li>
<li><strong>Algebra, Matrix Multiplications are optimized and much faster now</strong></li>
<li><strong>Algebra solving linear least squares problems</strong> in calculating <strong>homographies</strong> in the registration engine and finding <strong>Local Normalization Correction</strong> parameters are much faster and consume less memory</li>
<li><strong>Registration, the actual calculation of both the desciptors and the testing of matching patterns have been optimized</strong> which immediately gives better registration performance in the pattern matchin phase of registration</li>
<li><strong>Registration, implementation of KD-tree for pattern matching has been much improved</strong>, nearly no memory creation and much faster find of matching patterns</li>
<li><strong>Registration engine concurrency</strong> has been changed to make it faster</li>
<li><strong>Integration, optimized performance of reading the pixel stacks and integration them.</strong></li>
<li><strong>Integration, outlier rejection has been optimized </strong>no memory consumption/leak in stacker giving much more performance for both stacking calibration masters as light masters with MBB/drizzle weights</li>
<li><strong>Integration, big performance improvement in the file mapper for saving/loading all image parts in the stacks</strong> and when performing LNC and LN rejection, the read/write buffer sizes are now dynamic giving better performance beside faster implementation of the IO instructions to read/write data.</li>
<li><strong>Mutli-Band Blending</strong> has been optimized and is thus faster.</li>
<li><strong>Console Panel/Progess Monitors have been optimized</strong> to write progress fast and not block application performance using virtual threads</li>
<li><strong>Sorting of vectors/arrays performance and memory consumption has been improved</strong>, this is important in many calculations throughout the application</li>
<li><strong>CPU image viewer has a major performance boost !</strong> partly because of the improved and new image resampling/interpolation module and partly because of better concurrent implementation</li>
<li><strong>Normalization, advanced</strong> is much faster, the calculation of the overlap area has been optimized and the resampling of the overlap area is faster and of higher quality with the new resample engine.</li>
<li><strong>Preview filter is faster with faster statistics</strong> as mentioned above</li>
<li><strong>Statistics calculations have been optimized extensively. </strong>There is less memory consumption, code is faster as well. All statistics are calculated using a buffer : Analyse Tools as mentioned in the console. Analyse Tools has been greatly improved to give faster performance and not use extra memory while performing calculations. This buffer is fixed with 0,5 GB of RAM and is used from the Calibration engine until the Integration module.</li>
<li><strong>Median calculation</strong> has been greatly improved for speed and no memory consumption</li>
<li><strong>Median Absolution Deviation</strong> or <strong>MAD</strong> scale calculation performance and memory consumption improved</li>
<li><strong>Multi-Resolution Support Gaussian Noise estimate</strong> is much faster and uses less memory</li>
<li><strong>SNR calculation</strong> has been optimized and is much faster, consumes less memory partly because MRS noise has been improved.</li>
<li><strong>Biweight MidVariance for dispersion calculation is 10x faster</strong></li>
<li><strong>Lokation/sky background and dispersion calculation are optimized</strong>, faster and less memory consumption, this module is used in many parts of APP and thus improves performance in many parts of the application, most notably for the normalization engine</li>
</ul>
<p>&nbsp;</p>
<ul>
<li><strong>LICENSE SERVER VPN TUNNEL issue fixed</strong>
<p>Anyone that had issues to simply start APP, should try again now. On January 15th, our license server was upgraded with a new version with several improvements. The most important improvement is that we have fixed a network configuration issue that could have prevented APP to start normally in different situations like when trying to use APP on a remote computer over a VPN tunnel or another complicated network configuration. The problem was TCP/IP packet loss due to packet fragmentation when the remote computer had a high (1500)  MTU network setting. Normally the network interfaces solve this by interchanging ICMP packets, but our firewall was blocking these packets for security measures. We have removed the block of ICMP packets and this has solved the issue clearly. Other improvements are that the license activation and verification is slightly faster now, which also means slightly faster application startup.</p>
</li>
<li><strong>Upgraded OpenGL support with JOGL 2.6.0</strong>
<p>Support for OpenGL has been improved by uodating our JOGL dependency to 2.6.0 from 2.5.0. This has fixed several issues on all platforms especially the newer versions of macOS, Linux and Windows.</p>
</li>
<li><strong>Upgraded FITS read/write support to nom.tam.fits 1.21.2</strong></li>
</ul>
<p>&nbsp;</p>
<ul>
<li><strong>IMPROVED support for LINUX distributions with XWayland display server</strong>
<p>We have fixed many issues on Linux distributions that use the new XWayland display server instead of the old X11 display server. Both upgrading our development platfrom to Oracle JDK 25.0.2 and upgrading OpenGL support to JOGL 2.6.0 has solved many issues. Issues like broken/interrupted graphics rendering of the application, stalling/crashing application etc. <strong>Several test runs on Ubuntu 24 with XWayland now works really fine.</strong></p>
</li>
<li><strong>LINUX FIXED  X11Util.Display warning at APP shutdown</strong>
<p>If you would close APP with OpenGL enabled and the image viewer in the main panel, the below error/warning message would appear on the Linux terminal. This issue is solved by correctly closing OpenGL graphics hardware resources before closing APP.</p>
</li>
</ul>
<blockquote>
<p>X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 1/1, reusable (open, marked uncloseable): 0, pending (open in creation order): 1)<br />X11Util: Open X11 Display Connections: 1<br />X11Util: Open: NamedX11Display</p>
</blockquote>
<ul>
<li><strong>LINUX FIXED - solved and removed the warning Gdk-WARNING **: 22:01:01.835: XSetErrorHandler() called with a GDK error trap pushed. Don't do that.</strong>
<p>The APP 2.0 beta's had a GDK warning, which was harmless on older Linux Distributions. But on newer Distributions (with Wayland instead of X11) this warning was actual a critical problem. The warning would be shown in the Linux terminal, if you would start it from there. The issue has been solved by completely removing JavaFX from the APP project. JavaFX was responsible for the error and upstream could not solve the problem apparantly. APP used JavaFX to use native file/directory choosers. We no longer need to use JavaFX for this, since we found another way, see the next release note:</p>
</li>
<li><strong>FIXED, INTEGRATE PRE-NORMALIZED LIGHTS WITHOUT A REFERENCE IN THE FRAME LIST</strong>
<p>As mentioned in this thread <a href="https://www.astropixelprocessor.com/community/main-forum/app-beta-39-crashes-while-integrating-a-large-amount-of-frames/#post-33881" target="_blank" rel="noopener">https://www.astropixelprocessor.com/community/main-forum/app-beta-39-crashes-while-integrating-a-large-amount-of-frames/#post-33881</a> APP could crash if you load pre-normalized frames, thus skipping 5) NORMALIZE, and then rermove the reference frame from the list before starting integration. This bug is fixed.</p>
</li>
<li><strong>ADDED file filter for OM Digital Solutions ORF</strong></li>
<li><strong>Fixed several bugs in save/load of the application settings</strong></li>
<li><strong>Finally, we added many tests for all new improvements in our development environment</strong></li>
</ul>]]></content:encoded>
						                            <category domain="https://www.astropixelprocessor.com/community/"></category>                        <dc:creator>Mabula-Admin</dc:creator>
                        <guid isPermaLink="true">https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-2-0-0-beta40-release-notes/</guid>
                    </item>
				                    <item>
                        <title>Combining &quot;yesterdays&quot; RGB images LRGB</title>
                        <link>https://www.astropixelprocessor.com/community/tutorials-workflows/combining-yesterdays-rgb-images-lrgb/</link>
                        <pubDate>Sun, 05 Apr 2026 13:48:10 +0000</pubDate>
                        <description><![CDATA[I seem to have a total blackout....no idea what to do now. I processed yesterday raw files and ended up with L,R,G and B of course. Saved them and wanted to continue to get a final LRGB imag...]]></description>
                        <content:encoded><![CDATA[<p>I seem to have a total blackout....no idea what to do now. I processed yesterday raw files and ended up with L,R,G and B of course. Saved them and wanted to continue to get a final LRGB image. OK so far so good - loaded those four stacks and switched to "tools" and selected LRGB1. Now loading started and I was asked during loading what color I want to asign to Ch1, then Ch2, then Ch3 - because the stacked files are RGB. Now what to do, please? I have not idea, it is the first time that I want to contine working a day later..<br />Please help me and let me know what I need to do now..!</p>
<p>Thanks</p>
<p>Georg</p>]]></content:encoded>
						                            <category domain="https://www.astropixelprocessor.com/community/"></category>                        <dc:creator>Georg Nikolaus Nyman</dc:creator>
                        <guid isPermaLink="true">https://www.astropixelprocessor.com/community/tutorials-workflows/combining-yesterdays-rgb-images-lrgb/</guid>
                    </item>
				                    <item>
                        <title>White balance doesn&#039;t work for ASI585MC</title>
                        <link>https://www.astropixelprocessor.com/community/tutorials-workflows/white-balance-doesnt-work-for-asi585mc/</link>
                        <pubDate>Sat, 04 Apr 2026 14:30:52 +0000</pubDate>
                        <description><![CDATA[I&#039;ve computed the correct RGB white balance offsets for ASI585MC, and they work in GIMP but they do not work in APP:  These amounts should produce a balanced image, and do in other software ...]]></description>
                        <content:encoded><![CDATA[<p>I've computed the correct RGB white balance offsets for ASI585MC, and they work in GIMP but they do not work in APP:  These amounts should produce a balanced image, and do in other software but not in APP.    Please allow these RGB multiplier to work to set the white balance (its says custom white balance), and to save as presets per camera. </p>
10755]]></content:encoded>
						                            <category domain="https://www.astropixelprocessor.com/community/"></category>                        <dc:creator>Skye Goodrich</dc:creator>
                        <guid isPermaLink="true">https://www.astropixelprocessor.com/community/tutorials-workflows/white-balance-doesnt-work-for-asi585mc/</guid>
                    </item>
				                    <item>
                        <title>Today is the day then for version 2 beta 40 &#x1f600;</title>
                        <link>https://www.astropixelprocessor.com/community/main-forum/today-is-the-day-then-for-version-2-%f0%9f%98%83/</link>
                        <pubDate>Sat, 04 Apr 2026 08:19:01 +0000</pubDate>
                        <description><![CDATA[I guess today is the day for the new version 2, beta 40 release, as it’s 7 days after the 28th &#x1f973;&#x1f973;]]></description>
                        <content:encoded><![CDATA[<p>I guess today is the day for the new version 2, beta 40 release, as it’s 7 days after the 28th &#x1f973;&#x1f973;</p>]]></content:encoded>
						                            <category domain="https://www.astropixelprocessor.com/community/"></category>                        <dc:creator>Stewart William</dc:creator>
                        <guid isPermaLink="true">https://www.astropixelprocessor.com/community/main-forum/today-is-the-day-then-for-version-2-%f0%9f%98%83/</guid>
                    </item>
				                    <item>
                        <title>Allow specific values for RGB Multipliers not just Sliders (on 0 Color Settings) and saving Presets</title>
                        <link>https://www.astropixelprocessor.com/community/rfcs-request-for-changes/allow-specific-values-for-rgb-multipliers-not-just-sliders-on-0-color-settings-and-saving-presets/</link>
                        <pubDate>Sat, 28 Mar 2026 23:14:53 +0000</pubDate>
                        <description><![CDATA[Allow specific values to be entered for RGB Multipliers not just Sliders (on 0 Color Settings), and saving Presets, so I can save a Preset (R/G/B) white balance per Color Camera (not just DS...]]></description>
                        <content:encoded><![CDATA[<p>Allow specific values to be entered for RGB Multipliers not just Sliders (on 0 Color Settings), and saving Presets, so I can save a Preset (R/G/B) white balance per Color Camera (not just DSLR).   Many graphics software permit saving of white balance presets for the purpose.  </p>]]></content:encoded>
						                            <category domain="https://www.astropixelprocessor.com/community/"></category>                        <dc:creator>Skye Goodrich</dc:creator>
                        <guid isPermaLink="true">https://www.astropixelprocessor.com/community/rfcs-request-for-changes/allow-specific-values-for-rgb-multipliers-not-just-sliders-on-0-color-settings-and-saving-presets/</guid>
                    </item>
				                    <item>
                        <title>APP won&#039;t remember the Integrate Percentage Slider</title>
                        <link>https://www.astropixelprocessor.com/community/windows/app-wont-remember-the-integrate-percentage-slider/</link>
                        <pubDate>Sat, 21 Mar 2026 13:46:04 +0000</pubDate>
                        <description><![CDATA[Although most settings are stored between sessions, APP won&#039;t remember the integration percentage &quot;lights to stack&quot; such as if I set it on 90% one session, it forgets and goes back 100%.   S...]]></description>
                        <content:encoded><![CDATA[<p>Although most settings are stored between sessions, APP won't remember the integration percentage "lights to stack" such as if I set it on 90% one session, it forgets and goes back 100%.   Suggest have it remember what I set last time.  </p>]]></content:encoded>
						                            <category domain="https://www.astropixelprocessor.com/community/"></category>                        <dc:creator>Skye Goodrich</dc:creator>
                        <guid isPermaLink="true">https://www.astropixelprocessor.com/community/windows/app-wont-remember-the-integrate-percentage-slider/</guid>
                    </item>
				                    <item>
                        <title>what reasons can it have when integrating sony a7rv subs with astropixelprocessor that the stack show a lot of artefacts when a single sub does not, especially when the light pollution gradient is removed?</title>
                        <link>https://www.astropixelprocessor.com/community/main-forum/what-reasons-can-it-have-when-integrating-sony-a7rv-subs-with-astropixelprocessor-that-the-stack-show-a-lot-of-artefacts-when-a-single-sub-does-not-especially-when-the-light-pollution-gradient-is-rem/</link>
                        <pubDate>Thu, 19 Mar 2026 18:36:43 +0000</pubDate>
                        <description><![CDATA[Hello,
&nbsp;
been using APP with Nikon and ASI Zwo mono for a while, trying out a Sony a7rV
one subs looks like this after lightpollution:

&nbsp;
but doing a normal stack as usual, I...]]></description>
                        <content:encoded><![CDATA[<p>Hello,</p>
<p>&nbsp;</p>
<p>been using APP with Nikon and ASI Zwo mono for a while, trying out a Sony a7rV</p>
<p>one subs looks like this after lightpollution:</p>
10750
<p>&nbsp;</p>
<p>but doing a normal stack as usual, I kepp getting strange pattern when applying LP substraction:</p>
10752
<p>&nbsp;</p>
<p>any idea why? One subs is 30s, the stack 1 hour total</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>does APP apply LP too strong? Even if so these paatern should not appear. IN the single subs there is nothing</p>
10753]]></content:encoded>
						                            <category domain="https://www.astropixelprocessor.com/community/"></category>                        <dc:creator>elgol</dc:creator>
                        <guid isPermaLink="true">https://www.astropixelprocessor.com/community/main-forum/what-reasons-can-it-have-when-integrating-sony-a7rv-subs-with-astropixelprocessor-that-the-stack-show-a-lot-of-artefacts-when-a-single-sub-does-not-especially-when-the-light-pollution-gradient-is-rem/</guid>
                    </item>
							        </channel>
        </rss>
		