Problem with stacki...
 
Share:
Notifications
Clear all

19 June 2021: Our upload server https://upload.astropixelprocessor.com/ has been migrated successfully to our new office with higher upload and download speeds (nearly 10MByte/sec up/down ) ! We now have 1 general upload user called: upload with password: upload. The users upload1 - upload5 have been disabled.

31 May 2021: APP 1.083-beta2 has been released ! APP 1.083 stable will follow soon afterwards. It includes a completely new Star Reducer Tool, New File Saver Module, Improved Comet registration and much more, check the release notes here!

DOWNLOADS are available HERE!

 

Problem with stacking data from multi-scope system.  

Page 2 / 2
  RSS

(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3694
July 20, 2021 11:35  

Yes, we did right, 2 posts above I analyzed the issues in the darks and likely the bias frames. These might already explain some of the issues you have, did you retake the darks and bias to check?


ReplyQuote
(@mxcoppell)
Main Sequence Star Customer
Joined: 4 years ago
Posts: 28
July 20, 2021 15:55  

Thanks, Vincent.

But, the calibration frame is not the root cause of the issue we reported for the normalization (when choosing TOA-130 FOV as the reference). 

We've done tests with/without dark and got the same result. 

Have you tried to do the following 2 integration tests with Normalization, LNC, and MBB enabled? 

  • Use the best scored TOA-130 light frame as the reference
  • Use the best scored FSQ-106 light frame as the reference

Thanks!


ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3694
July 20, 2021 17:39  

Ok, I will analyze the data further, I was hoping it was the calibration data. 🙂 Sorry for the time it takes, this can happen due to the busy schedule sometimes. Please allow for 1-2 days.

 


mxcoppell liked
ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3694
July 23, 2021 13:19  

Going to let APP process the data now..


mxcoppell liked
ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3694
July 23, 2021 15:44  

Ok, got the first data processed with the reference set to a 530mm focal length frame. I used 1.083-beta 2 of APP on Linux. These are the settings I used:

- In tab 0; select Ha for the algorithm
- In tab 1; I loaded the data of both scopes in 2 sessions, I didn't use calibration data
- In tab 4; I used dynamic distortion correction and switched "same camera and optics off", registration mode normal
- In tab 5; I switched to advanced mode as this is required for this type of data
- In tab 6; MBB and LNC were switched on with their default values

This came out:

500mm ref integration

Then, some light pollution correction:

500mm ref integration lpc

Amazing data btw!

Other way around, same settings as mentioned above, now with a 1000mm focal length sub as reference. This made APP complain a bit with registration, so I increased the number of stars to 1000 and scale stop was set to 10.

This came out:

1000mm ref integration

Corrected:

1000mm ref integration lpc

mxcoppell liked
ReplyQuote
(@mxcoppell)
Main Sequence Star Customer
Joined: 4 years ago
Posts: 28
July 23, 2021 16:00  

Thanks, Vincent! It's about the same result here. 

"Corrected" - How is this done?


ReplyQuote
(@mxcoppell)
Main Sequence Star Customer
Joined: 4 years ago
Posts: 28
July 23, 2021 16:30  

I looked carefully into it. Still can see the uneven normalization between the two FOVs. Especially for the case with 1000mm FOV as the reference. Even a large value of MBB is applied, my guess is that there is not enough information to normalized the bigger FOV frames from the 530mm. 

The purpose we use the 1000mm FOV as the reference is trying to retain the details from the larger scope - at the same time, normalization should be done with the 530mm FOV reference. Could this be done?  


ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3694
July 23, 2021 17:18  

@mxcoppell Corrected was done using Light Pollution Correction in the tools menu.

Biggest difference with your workflow I think, was that I didn't use mosaic mode (this isn't a mosaic). You followed my settings I guess? If so, I'm not sure what you're seeing as the data looks really good to me. There is of course more data now for the center part of the image so slight differences compared to the outer part might be visible. Normalization is, as far as I know, done on the whole dataset.


ReplyQuote
(@mxcoppell)
Main Sequence Star Customer
Joined: 4 years ago
Posts: 28
July 23, 2021 17:31  

Yes, Vincent. In my latest test, I am using exactly the same setup as yours (no more mosaic). The concern is still about the normalization - if the normalization is done on the whole dataset, including the 1000mm and 530mm FOV, the reference frame of 1000mm should not be used as the normalization reference right? It doesn't have the data to cover the 530mm FOV. 

Could that be the reason the brightness of the 1000mm FOV area is much brighter than the outer 530mm FOV area, and lost much of the contrast in the integration result. 


ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 4 years ago
Posts: 3694
July 23, 2021 19:00  

My feeling is that this difference is likely due to the fact there is more data in the middle. But I'll pass this question on to Mabula as I'm not sure this is the correct feeling.

 


mxcoppell liked
ReplyQuote
(@mxcoppell)
Main Sequence Star Customer
Joined: 4 years ago
Posts: 28
July 23, 2021 19:03  

Thank you for all the support, Vincent! 

Agreed that the overlapped area from both FOVs has more data. We are expecting higher SNR and contrast here - but want to retain the uniformed brightness across the FOV of the whole frame.


ReplyQuote
Page 2 / 2
Share: