Normalization error...
 
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.

 

Normalization errors after registration issues

10 Posts
3 Users
3 Likes
614 Views
(@cdp17)
White Dwarf
Joined: 4 years ago
Posts: 9
Topic starter  

Hi all,

Because of a software error in the telescope setup, during a meridian flip half of my images ended up being mirrored and flipper per se when a meridian flip occurred; and so they failed registration.  I tried to deal with this by making the following changes to the Registration step:

  • Checked 'flip x/y'.
  • Unchecked 'same camera and optics'
  • Changed the registration from 'quadrilaterals' to 'triangles'

Now registration succeeds, but then I get a series of errors in Normalization, like this:

image

Just to see what was happening, I temporarily disabled normalization, and after RGB combine, this is what my image looks like:

image

(The individual channel files look pretty much like that too.  I suspect that normalization is failing when trying to normalize the leftover margin areas after registration.

Any suggestions for how to deal with this, so normalization succeeds?  (My thought was to save the registered frames, then bulk crop them, then resume integration with the cropped frames – but I’m not exactly sure how to do that, or if that’s even the correct approach.)

It’s also possible that my approach for handling the mirrored subs in Registration is not correct.

Thanks,

Charles


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

Mmm, I think it's best for us to have a look at the data. Would you mind uploading a small subset of your data? Like 10 lights, 10 darks, etc. ?


   
ReplyQuote
(@cdp17)
White Dwarf
Joined: 4 years ago
Posts: 9
Topic starter  

I have uploaded 6 files each of LRGB to folder "cdp17-registration".   They are all light files (already calibrated by iTelescope before being delivered to me).

BTW the version I am running is 1.083.4, which I believe is the latest.

I appreciate you looking into this!

Charles


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

Ah, precalibrated. Mmm, if I'm right iTelescope also provides the calibration files seperately and raw lights. I think it will be very informative if you can get those and upload as well as this may very well be a calibration issue. This is better anyway as APP will have better calibration algorithms to use.


   
ReplyQuote
(@cdp17)
White Dwarf
Joined: 4 years ago
Posts: 9
Topic starter  

Hi Vincent,

I will try to get the raw lights and calibration files (I hope the raw files haven't been removed from the iTelescope FTP site yet), but it may take a few days.

In the meantime, I do see something suspicious in APP.  If I examine these files with an external FITS viewer (AvisFV), all of the files look normal, except that the "W" images (after meridian flip) are mirrored:

image

However, inside APP, with the image viewer the "E" images look normal, and as they do in AvisFX; but every one of the "W" images has a histogram that does not look right, and the image is all wrong (it's supposed to be monochrome, for one thing):

image

I am not experienced enough to know whether this indicates image issues or an APP issue, but I thought I'd bring it up as a data point.

Thanks again,

Charles


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

The external application shows a very stretched result, it's not possible to judge what is going on in the background there. Also if they are mono, then it seems the data has a wrong header tag maybe, does it show an RGB pattern in the fits header?

Anyway, when you have the data, please let me know and we can probably tell you what is going on. For now this does look like a data issue.


   
ReplyQuote
(@cdp17)
White Dwarf
Joined: 4 years ago
Posts: 9
Topic starter  

Hi Vincent,

Thanks to the excellent iTelescope support staff, the issue is resolved.  In a nutshell:

  • Software bug on telescope system introduced a spurious “BAYERPAT” line in the FITS header after a meridian flip.
  • This line made APP believe that the camera has a Bayer mask when in fact it does not; hence the incorrect image viewer/histogram, and the failure to integrate.
  • Two workarounds were successful:
  1. Use current version of APP with “no interpolation” on tab 0
  2. Use older version of APP (1.078) which (apparently) does not pay attention to the BAYPERPAT line in the header

The idea that the incorrect BAYPERPAT line fooled APP is just a working theory, but in conforms with the workaround results.  In any case, this should not happen again since the iTelescope team has corrected the processing error on the telescope system.

I very much appreciate for your offer to help, but I’m glad I did not waste your time on what in fact turned out to be an image issue – as you suspected from the start.

Cordially yours,

Charles


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

Thanks for coming back to explain what happened Charles! That is very helpful. Glad it's figured out.

The BAYERPAT line indeed fooled APP as it does expect that tag to be correct. This was indeed introduced in a later version.


   
ReplyQuote
(@wvreeven)
Quasar
Joined: 6 years ago
Posts: 2133
 

@cdp17 There is a third option: remove the BAYERPAT FITS keyword from the raw files. This is possible via the tools in the Tools tab of APP.


   
ReplyQuote
(@cdp17)
White Dwarf
Joined: 4 years ago
Posts: 9
Topic starter  

Wouter, thank you for drawing my attention to that feature - I wasn't aware of it!

Charles

 


   
ReplyQuote
Share: