Field rotation caus...
 
Share:
Notifications
Clear all

15th Feb 2024: Astro Pixel Processor 2.0.0-beta29 released - macOS native File Chooser, macOS CMD-Q fixed, read-only Fits on network fixed and other bug fixes

7th December 2023:  added payment option Alipay to purchase Astro Pixel Processor from China, Hong Kong, Macau, Taiwan, Korea, Japan and other countries where Alipay is used.

 

Field rotation causes a huge integration frame: can I predefined a crop?

6 Posts
2 Users
2 Likes
449 Views
(@readyjetty)
Neutron Star
Joined: 2 years ago
Posts: 75
Topic starter  

I have a very odd, non standard, set up.  I do a bit of deep sky imaging with my Orion XT12G Alt/Az Dob.  Actually get pretty good results but there is one problem I have and it causes APP to occasionally explode in disk, memory usage, and integration time.

My telescope has field rotation, and it can slowly drift a bit off target occasionally before it reslews back onto target.  APP does a good job of stacking all these miss registered and rotated frames and I just crop the data afterwards.  However it creates a gigantic integration frame which causes APP to explode in resource and time usage.

Also because my tracking is mediocre I take short subs, like 8 to 12 seconds, so I can end up with a couple of thousand lights.  That coupled with the giant integration frame from field rotation and small positioning drifts creates crazy resource usage.

I’m looking for strategies to deal with this.  Suggestions are appreciated.

I wish I could select a master frame and say crop to this master frame when integrating, ignore any other data outside of this when you’re integrating and don’t turn a 24 megapixel master frame into a 70 megapixel super integration mosaic.

I expect this would cut down the resources required and the amount of memory required to do a stacking.  Because right now I have situations where it requires 3-4 TB of disk working space to integrate and takes 8-12 hours on an 8 core AMD 5900 CPU with 16 gigs RAM and a fast SSD.

it sometimes crashes also.

Where is a mitigate this today are:

1) capture in bin2 for these larger integrations 

2) presort the frames by deleting ones that I won’t want (poor star FWHM)

3) integrate with a scale <1

these are helpful but some lower the resolution of the final result when I really just want the frame to be cropped.

 

 

 

This topic was modified 2 years ago by Steven Miller

   
ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 7 years ago
Posts: 5707
 

Yes, 1000's of frames is a challenge. What I would do is to process those in batches. Integrate, say, 300-400 frames at a time, fully calibrated and integrate them. Do this until you have a number of integrations. These integrations can be loaded in again as lights, without calibration data and then integrated again.


   
ReplyQuote
(@readyjetty)
Neutron Star
Joined: 2 years ago
Posts: 75
Topic starter  

Great idea!  I forgot I could integrate previous integrations.  What is the particular file for the previous integration I should use?  Should I save an unstretched TIFF or is it one of the auto saved files?


   
ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 7 years ago
Posts: 5707
 

You mean what you then pick as a reference frame? Maybe you can add the same file to each of the integrations and reference that one? Never tried that myself though. 🙂


   
ReplyQuote
(@readyjetty)
Neutron Star
Joined: 2 years ago
Posts: 75
Topic starter  

@vincent-mod actually, I mean as the new lights, I expect it’s just the unstretched .FITs file APP spits out after stacking.


   
ReplyQuote
(@vincent-mod)
Universe Admin
Joined: 7 years ago
Posts: 5707
 

Oh, right, yes just the integrated result that APP saves, which is a linear (unstretched) .fit file.


   
ReplyQuote
Share: