PixInsight 1.8.8-10 Released

I processed this data with previous versions as well and see this different result only since this last version.
I’m not aware of any other changes.
I was suspecting the PSF weighting features came along some changes how PSFs are computed which is related to my issue.
 
There are no changes in the DynamicPSF tool either. Our PSF fitting code has undergone substantial optimizations, but none of these changes can alter measured PSF parameters. Our PSF fitting routines are as robust and accurate as they always have been, and they have been subject to intensive testing work during the development of the new image weighting algorithms. So what you are reporting is strange. Can you show an example of the changes that you are observing, such as a before/after comparison between PSF measurements?
 
Luckily, I have the project file for the last edit with the older PI version still available.
What I noticed, the new PSF is substantially larger.

psfs.jpg

The workflow did not change. I use DynamicPSF to select stars with amplitude between 0.3 and 0.7 with auto-modeling and create the PSF.
The base data was not drizzled, it is the exact same size.
 
Yes, here you go: https://www.dropbox.com/sh/30zqi90xyfbc7k9/AAAkO6cdxvySYozdiB5GKtEYa?dl=0

Prefix OLD and NEW indicate which PI version was used to align, stack and process.
After integration only DynamicCrop and DBE was performed.

I also loaded up the old project data with the blocky PSF and used DynamicPSF again to create a PSF and it came out like above again (larger, more oversampled looking). There's something happening somehow.

Let me know if you need more data/information.

Thank you for looking into this!
 
Thank you for uploading the images. The old and new integrated images are very different, and the differences have nothing to do with PSF fitting. The images show completely different aliasing artifacts caused by image registration, so the cause of these differences is, with very high probability, different pixel interpolation algorithms applied with the StarAlignment process. I see no software problem here; just the results of different working parameters.

From the metadata in these integrated images I cannot know how the individual frames have been registered. Anyway, this announcement post is not the right place to report these problems, so if you still think that there is a bug or some other problem with PixInsight, please open a new thread on the General or Bug Reports board, as appropriate. I'll probably ask you to upload the entire data set, or at least a relevant part of it where the problem can be reproduced.
 
With the Oiii set of this project, I had massive problems using the Lanczos-interporlation during StarAlignment. It always left a weave pattern in the background that ruined the entire stack (it became visible after noise reduction and star removal).
The only fix was using BicubicBSpline interpolation. I used this on both Ha and Oiii stacks. Why the aliasing artifacts differ that much between both Ha stacks (old and new PI), I cannot say, I used the same conditions for both alignments/stacks.

Alright, let's stop here. I won't bother with Deconvolution on this partical project then (the sub count is too large and the time I threw into this is already past any reason).
Let's see what future sets will show. If I stumple upon this again, I will address it in a dedicated thread. Thanks again!
 
The only fix was using BicubicBSpline interpolation.
Click to expand...

Bicubic B-Spline is one of the worst options in terms of aliasing. Bear in mind that aliasing destroys image resolution. Have you tried increasing decreasing the clamping threshold parameter and using Bicubic Spline instead of Lanczos?

If the data is extremely weak, clamping may not be sufficient, but in these cases you can follow a different strategy: use bilinear interpolation for registration, but perform a drizzle integration after normal integration to generate the final integrated image. Drizzle integration does not interpolate the data, so the resulting image will be pristine.
 
I went down to 0.1 for clamping while testing without success.
The problematic data is around 20h of Oiii for the squid, however the background may still be weak due to the lack of signal anywhere except for the squid itself.
I‘ll try your suggestion using bilinear interpolation and drizzle (if my Mac survives drizzling 300 subs).

Would you suggest to keep the reference frame inside the Oiii set or can I use the best Ha frame?

I‘ll open up a thread if I still see the ripple/weave pattern to get an expert opinion on how to fix it. Thanks!
 
Would you suggest to keep the reference frame inside the Oiii set or can I use the best Ha frame?
Click to expand...

It will work both ways. However, if you are going to generate a composite color image, better use a unique alignment reference frame for the whole data set. Otherwise you'll have to apply additional interpolation to register the integrated channel images before combining.
 
Juan Conejero said:
It will work both ways. However, if you are going to generate a composite color image, better use a unique alignment reference frame for the whole data set. Otherwise you'll have to apply additional interpolation to register the integrated channel images before combining.
Click to expand...
Yes, I meant because of the problematic nature of this Oiii set to keep the reference in this set and then register all Ha frames to this best Oiii frame as well.
Not sure if choosing the reference for all subs in the Ha set introduces another variable in this problematic Oiii set.
 
maybe you just need to add an output pedestal to the calibration process. with narrowband subs where there is low signal the darks may naturally exceed the lights in some pixel locations and leave a pattern of 0-valued pixels in the calibrated lights. then after registration you get funny moire patterns which show up in the integration.
 
pfile said:
maybe you just need to add an output pedestal to the calibration process. with narrowband subs where there is low signal the darks may naturally exceed the lights in some pixel locations and leave a pattern of 0-valued pixels in the calibrated lights. then after registration you get funny moire patterns which show up in the integration.
Click to expand...

Can you show an example image with these artifacts?

@Mods: can you split this discussion into its separate thread?
 
Juan Conejero said:
Very strange. I cannot reproduce this problem. It works perfectly at least on three machines that I have at hand here now.
Click to expand...

I am seeing the same issue. I highlight a block of subs in the results window of subframe selector and when I toggle approved a random set of subs are toggled. In addition to the green check toggling on the random subs the lock is also toggled. I tried restarting PI but no change.
 
I have no idea how much work goes into making all the improvements that go into so complex a program, but I do appreciate it. However, I am a bit dismayed that all of these improvements come with a significant (to me and other users, I suspect) cost. My main image processing computer, indeed my workhorse everyday useitforeverything computer is a MacBookPro that says mid-2012. So now I have a choice: keep using 1.8.8.9, where everything works fine including StarNet, or go for all the upgraded processes but no StarNet. I would argue that for most entry-to-low-end users, StarNet is one of the great things to use in PI. All of the other stuff you are so chuffed about goes right over our heads, or past our eyes, for the most part. Is there a way of adding the most significant part of the new version (in my opinion) which is tracking the processing history to the 1.8.8.9 version, thus keeping StarNet available to the great unwashed like me who chisel our notes onto stone tablets? Otherwise, unless I can miraculously become a mask-making wizard and PixelMath savant, I and others face the prospect of having to buy a new computer to use the newest version of PI in the same way we used the last version. Unless you have a workaround that you haven't told us about....And I know I could just save things as a project--not my point, exactly.
 
if .9 works with starnet, then .10 will work with starnet... nothing should have changed there.

rob
 
Thanks Rob for this information. I can indeed get StarNet to work, but when I first tried it after updating to .10, I got a red warning in the process console ending in Failed, I think, and nothing happened. I tried again; again nothing. Because I had read Juan's advisory note about pre-2013 Intel processors and M1 processors, and seeing in About my Mac that I have a MacBook Pro mid-2012 with a 2.5 GHz DualCore Intel Core i5, a pretty lowly beast, I didn't expect it to work. And, in those first attempts, it didn't, which led to my post above.

Since that post, I have restarted my machine for other reasons and have restarted PI .10 and now all is well. So it probably doesn't matter why it didn't work the first time. Maybe something in the way my process icons loaded or something--I have no clue. I hope I am only coming across as someone who gets a bit baffled by some of this stuff and not just a cranky old fart. Which my kids sometimes accuse me of being. But I'm not.
 
It's always great to see an update, but I have to ask, will we ever get a decent updater?
It's really tedious having to uninstall and install each time that way, especially when custom files/scripts aren't saved when you uninstall and you have to back it up, uninstall, install and then configure it again.
I wish it could've been improved.

Thanks for the work.
 
Incremental updates to the core application are not possible on macOS and Windows because they invalidate digital signatures and notarization. This means that the core executable on Windows and the entire application on macOS cannot be altered in any way, not even a single bit in a plain text file. The only way to update them is through a complete reinstall. Other applications that release software without digital signatures may not have this problem, but that is not the case of PixInsight.

On the other hand, when we release a new version we normally change many files in the distribution besides the core executable. The PixInsight software distribution is quite complex with hundreds of interdependencies among components. It resembles an operating system in many aspects. Many files change, there are new files, and others are removed or relocated. The only way to guarantee total coherency (and hence to prevent a complete disaster) is by performing a complete, clean reinstall of the entire package after deleting all traces of the previous one.

Official modules and scripts are always carefully updated, packaged and preserved across releases. Unofficial update repositories are also preserved so you shouldn't need to specify them after installing a new version. Of course, unofficial products released by third-party sources are not under our control and must be reinstalled. However, if those third parties do their job correctly this shouldn't be a problem at all because the scripts or modules in question should be available immediately as an update; having them installed back should be a matter of minutes.
 
I have another problem.
Updating some of my scripts using the update routine went wrong somehow so I decided to install a completely new PI installation.
Upon starting, a few bugfix updates are prompted. Somehow, after installing them, SubFrameSelector is broken.

PI.jpg

macOS 12.0.1
PI 1.8.8-10
SubframeSelector module version 1.6.5 (update/bugfix)
 
You must log in or register to reply here.
Back
Top