It did take a long time to have the work finished on this and it will have a major performance boost of 30-50% over 2.0.0-beta39 from calibration to integration. We extensively optimized many critical parts of APP. All has been tested to guarantee correct optimizations. Drizzle and image resampling is much faster for instance, those modules have been completely rewritten. Much less memory usage. LNC 2.0 will be released which works much better and faster than LNC in it's current state. And more, all will be added to the release notes in the coming weeks...
Update on the 2.0.0 release & the full manual
We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.
Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.
I had beta 34 earlier and installed beta 36 today. I'm getting some weird issues, which I'm not sure what's causing or what's the actual resolution
Issue 1 . I integrated some HA data (pretty basic 10 frames of Orion and then 8 frames of widefield MW - separately) and the stacked result ended up looking like a whirlpool. I disabled the registration and then the result looked perfect. Then I enabled registration and the result was as expected. I closed down APP and did this again and same issues appeared again. This also happened while integrating Attaching an screenshot showing what it looked like. Any explanation for this? I haven't seen this happening before beta 34.
Issue 2: I integrated some HA data (again pretty basic 8 frames of widefield MW) and the stacked result ended up as grayscale image. I checked the forum and there was some suggestion to enable "Force Bayer\Xtrans CFA" to resolve this issue, but this didn't make a difference in my case. Any ideas, what could be causing this? The data was loaded as extract HA in the Raw\Fits tab.
Attaching screenshot showing both issues for the stack of MW images and the Orion stack
@bikramghosh I have no idea why you got those weird images, but regarding the Ha stack being grayscale, you have not mentioned what camera you are using. But the reason why your Ha image is grayscale is because it is a "Hydrogen Alpha" image and not an RGB image.
This post was modified 12 months ago by Simon Todd
@bikramghosh Ok now it makes more sense. When you select a colour filter to load up the lights, in this case "Hydrogen Alpha" then it is going to be regarded as Monochrome Data. The same would apply if you loaded the same data up against any particular channel, R, G, B etc. When you load up the frames you should load them up with the following option enabled:
Hi Simon(@sastro), as noted in my post, I did try with that enabled ad well - after seeing a suggestion about it in another thread. Will try to attacha video to show all the menu.
Thanks.
This post was modified 12 months ago by Bikram Ghosh
@bikramghosh The image files have been allocated to "Hydrogen Alpha" channel means that they will be regarded as Grayscale:
When you loaded the frames, and the Dialog box appeared asking which channel you wanted to assign them to, you chose Hydrogen-Alpha, when you should really have chosen the option at the bottom:
With the Force Bayer option, and the above option, they should then be loaded up as RGB frames, do not assign them to the Hydrogen-Alpha filter option.
@sastro i thought that was only for distinguishing files for different types / color coding etc and not for actual data extraction. That's done based on what's selected in Raws tab. Anyhow, I felt a moment of hope and tried your suggestion. But same result.
I have uploaded another screen recording in the same gdrive locatio as above
@bikramghosh Thank you. This has something to do with the Interpolation settings, the Camera uses a VNG interpolation, I have tested using a few of the interpolation methods and I can show it as a colour image using different Interpolation Methods, here's an example of one:
I loaded your frame into another program and performed a standard auto stretch, and it looks exactly like the above image:
You will also see that I have the image loaded as RGB, as opposed to Mono or Hydrogen-Alpha. Since you are using Hydrogen Alpha, you should use an Interpolation Method that only pulls the Ha Data for example as follows:
So I do not think anything is wrong here, the Ha data in my opinion would be Monochrome anyway in order to add it to a normal RGB Image, especially since only the Red Pixels on the CFA will be receiving data due to the Ha Filter
Hi Simon(@stastro), I won't pretend I know a lot about APP as I'm a fairly new user . But I have tried these settings before in another version for my HA stack and it did work seamlessly before. I have also seen youtube videos before I started with APP, demonstrating this very step.
From what I could recollect - if you load mono images you will get mono output, which I'm fine with. But if what gets loaded is RGB the output it also RGB color space with only R channel data for H-alpha.
I think what you have explained makes perfect sense for mono imaging.
@mabula-admin - could you please shed some lights on this?
Your image is being loaded as RGB space, you can clearly see from the file parametes in the file list that it has been loaded as RGB. The problem here is the correct interpolation method for your camera.
With no Interpolation this is the result:
If I choose Bilinear, adaptive edge or adaptive airy disc as the Interpolation method, I now get a Red image (Which proves it has been loaded as RGB):
If I choose Super Pixel, I get a slightly different red image:
You can even see from the Histogram in the top right hand corner that this is indeed a colour image when using an appropriate interpolation method:
So your image is colour, you just have to choose an appropriate interpolation method.
The above red images are similar to what I get when I load it up in other tools, which re-inforces the need for you to choose an appropriate interpolation method. I am not sure why VNG Interpolation is not being picked up automatically though. But then Fred Vanner has done a lot of work on interpolation methods and calls out why ones like VNG are not ideal for Astrophotography, and maybe this is why it is not picked up in APP because of its drawbacks for Astro use.
From another tool the header info:
Camera ............ Nikon D850
Timestamp ......... 2024-04-05T23:30:03Z
Time offset ....... +02:00
Exposure .......... 123s
ISO speed ......... 1600
Focal length ...... 28.00 mm
Aperture .......... f/1.40 = 20.00 mm
Author ............ www.avisekhphotography.com
CFA pattern ....... Bayer RGGB
Raw dimensions .... w=8288 h=5520
Image geometry .... x=0 y=0 w=8288 h=5520
Raw decoding parameters:
Output mode ............... demosaic
Interpolation ............. VNG
Interpolate as 4 colors ... disabled
FBDD noise reduction ...... 0
Wavelet noise threshold ... 0
White balancing ........... camera
Black point correction .... enabled
Highlights clipping ....... enabled
Auto rotate ............... enabled
Output image .............. w=8288 h=5520 n=3 RGB
So you can see that VNG is the Interpolation. I would probably air on the side of the Airy Disc interpolation. It's been a long time since I imaged with a DSLR and that was way before I started using APP, as I started by using Nebulosity, which had a method to demosaic and square raw.
Rest assured, your image is being loaded as colour, as I said, just choose an appropriate interpolation method
Also to re-inforce this is a colour image, I performed a split RGB from the original file and as a result:
Blue:
Green:
Red:
The red output looks very similar to the image when selecting Hydrogen-Alpha as the Interpolation method. So your image is fine, your data is fine, just choose an appropriate interpolation method
I had beta 34 earlier and installed beta 36 today. I'm getting some weird issues, which I'm not sure what's causing or what's the actual resolution
Issue 1 . I integrated some HA data (pretty basic 10 frames of Orion and then 8 frames of widefield MW - separately) and the stacked result ended up looking like a whirlpool. I disabled the registration and then the result looked perfect. Then I enabled registration and the result was as expected. I closed down APP and did this again and same issues appeared again. This also happened while integrating Attaching an screenshot showing what it looked like. Any explanation for this? I haven't seen this happening before beta 34.
Issue 2: I integrated some HA data (again pretty basic 8 frames of widefield MW) and the stacked result ended up as grayscale image. I checked the forum and there was some suggestion to enable "Force Bayer\Xtrans CFA" to resolve this issue, but this didn't make a difference in my case. Any ideas, what could be causing this? The data was loaded as extract HA in the Raw\Fits tab.
Attaching screenshot showing both issues for the stack of MW images and the Orion stack
Issue 1: the whirlpool result will happen if you enable dynamic distortion correction when your data does not need it. So simply leave registration enabled and disable dynamic distortion correction, then the result should be perfect. The whirlpool is created through mathematical instability which is an issue we need to fix and is on our issue list. But for now simply disable dynamic distortion correction and all should be fine.
Issue 2: I have not looked at your data myself, but Simon's replies indicate that you are in fact using a color camera, right? So normally APP will automatically recognize that you use a color camera through the metadata in the file header's, put there by the capture software or hardware. If that metadata is not there, the force Bayer/XTrans CFA option forces APP to interpret the data as CFA = Color Filter Array data, that means that it is color data that still needs to be debayered. What do you see in the CFA column in the frame list panel when your frames are loaded? If it shows a pattern like RGGB, then APP recognises that it is color data that needs debayering. If it says no, then it does not recognize it.
Finally, CFA data that is debayered would produce a color/ RGB image normally, but if you set the demoniac algorithm to one of the narrowband algorithms like H-alpha or Ha-O3 extract Ha, then the narrowband data is still debayered as it should, but only the color channel (R,G,or B) will be shown in monochrome, so for H-alpha, that means that the red channel is debayered and then shown in black and white. This is the expected behaviour.
Hope this clarifies everything?
Mabula
This post was modified 12 months ago by Mabula-Admin
Hi Simon(@stastro), I won't pretend I know a lot about APP as I'm a fairly new user . But I have tried these settings before in another version for my HA stack and it did work seamlessly before. I have also seen youtube videos before I started with APP, demonstrating this very step.
From what I could recollect - if you load mono images you will get mono output, which I'm fine with. But if what gets loaded is RGB the output it also RGB color space with only R channel data for H-alpha.
I think what you have explained makes perfect sense for mono imaging.
@mabula-admin - could you please shed some lights on this?
Thanks
If RGB data is loaded that still needs to be debayered, but a narrowband debayer algorithm is selected like H-alpha, then the result becomes monochrome which is the expected behavior indeed.
Your image is being loaded as RGB space, you can clearly see from the file parametes in the file list that it has been loaded as RGB. The problem here is the correct interpolation method for your camera.
With no Interpolation this is the result:
If I choose Bilinear, adaptive edge or adaptive airy disc as the Interpolation method, I now get a Red image (Which proves it has been loaded as RGB):
If I choose Super Pixel, I get a slightly different red image:
You can even see from the Histogram in the top right hand corner that this is indeed a colour image when using an appropriate interpolation method:
So your image is colour, you just have to choose an appropriate interpolation method.
The above red images are similar to what I get when I load it up in other tools, which re-inforces the need for you to choose an appropriate interpolation method. I am not sure why VNG Interpolation is not being picked up automatically though. But then Fred Vanner has done a lot of work on interpolation methods and calls out why ones like VNG are not ideal for Astrophotography, and maybe this is why it is not picked up in APP because of its drawbacks for Astro use.
From another tool the header info:
Camera ............ Nikon D850
Timestamp ......... 2024-04-05T23:30:03Z
Time offset ....... +02:00
Exposure .......... 123s
ISO speed ......... 1600
Focal length ...... 28.00 mm
Aperture .......... f/1.40 = 20.00 mm
Author ............ www.avisekhphotography.com
CFA pattern ....... Bayer RGGB
Raw dimensions .... w=8288 h=5520
Image geometry .... x=0 y=0 w=8288 h=5520
Raw decoding parameters:
Output mode ............... demosaic
Interpolation ............. VNG
Interpolate as 4 colors ... disabled
FBDD noise reduction ...... 0
Wavelet noise threshold ... 0
White balancing ........... camera
Black point correction .... enabled
Highlights clipping ....... enabled
Auto rotate ............... enabled
Output image .............. w=8288 h=5520 n=3 RGB
So you can see that VNG is the Interpolation. I would probably air on the side of the Airy Disc interpolation. It's been a long time since I imaged with a DSLR and that was way before I started using APP, as I started by using Nebulosity, which had a method to demosaic and square raw.
Rest assured, your image is being loaded as colour, as I said, just choose an appropriate interpolation method
All software that needs to process color images that need to be debayered/demosaiced need demosaic algorithms. We deliberated chose to not implement VNG demosaicing in APP. Instead we developed and wrote our own demosaic algorithms. Many astro packages are lazy and do not implement this themselves but rather use this from 3rd party developers like the raw conversion by LibRaw that provides VNG. That explains why other packages often use VNG 😉