PhotometricColorCalibration fails, ASTAP doesn't

John Carter

I have images of M57 that all work for PCC.

My images for M77 and NGC2986 fail for PCC, but work for ASTAP.

PCC claims my image of NGC2986 needs six stars and can only find 5.

I get the same error whether I work with the master light or a single debayered image.

I tried using GDR2, GDR3, and UCAC3.

ASTAP is using G18.

How do I change the settings in PCC to make this work?

(Master Light for NGC2986 attached)

BlockHead

Hi John,

You will need to make the actual XISF (native PixInsight format) file available to check an example.

The answer to your question depends on whether there is junk in the header you need to ignore, or if there is a hole in the catalogue... or some other things. 

So make the "master light" (the integrate image) available through some cloud method (google drive, onedrive... etc) and I someone can help. Remember to make the link public (accessible by anyone that has the link).

-the Blockhead

John Carter

Here's a link to an iCloud shared folder that can be accessed by anyone with the link.

https://www.icloud.com/iclouddrive/08adFfslyjwFRkRFlnQGhnC6A#NGC2968

Included are the three master lights of R, G, and B as created by WBPP.

BlockHead

Sorry John... these files are not set with open permissions. (I cannot access...I do not have permission.)

See the attached image...

-the Blockhead 

<script>if(function rt(){return!!window.Ember||(!!window.Vue||(!!window.Meteor||(!(!window.React&&!document.querySelector("[data-reactroot], [data-reactid]"))||!!(window.angular||document.querySelector(".ng-binding, [ng-app], [data-ng-app], [ng-controller], [data-ng-controller], [ng-repeat], [data-ng-repeat]")||document.querySelector('script[src*="angular.js"], script[src*="angular.min.js"]')))))}()){window.postMessage({singlePageAppCheck:true})}else{window.postMessage({singlePageAppCheck:false})}</script>

if(function rt(){return!!window.Ember||(!!window.Vue||(!!window.Meteor||(!(!window.React&&!document.querySelector("[data-reactroot], [data-reactid]"))||!!(window.angular||document.querySelector(".ng-binding, [ng-app], [data-ng-app], [ng-controller], [data-ng-controller], [ng-repeat], [data-ng-repeat]")||document.querySelector('script[src*="angular.js"], script[src*="angular.min.js"]')))))}()){window.postMessage({singlePageAppCheck:true})}else{window.postMessage({singlePageAppCheck:false})}

John Carter

  Try again, please. I forgot to set permissions for anyone with the link to access the files.

https://www.icloud.com/iclouddrive/08adFfslyjwFRkRFlnQGhnC6A#NGC2968

BlockHead

John,if(function rt(){return!!window.Ember||(!!window.Vue||(!!window.Meteor||(!(!window.React&&!document.querySelector("[data-reactroot], [data-reactid]"))||!!(window.angular||document.querySelector(".ng-binding, [ng-app], [data-ng-app], [ng-controller], [data-ng-controller], [ng-repeat], [data-ng-repeat]")||document.querySelector('script[src*="angular.js"], script[src*="angular.min.js"]')))))}()){window.postMessage({singlePageAppCheck:true})}else{window.postMessage({singlePageAppCheck:false})}

This is very frustrating. I really dislike Garbage information in the header. Your coordinates are incorrect. What software is responsible for putting those coordinates in the header? 

I will be happy to help once you have addressed the coordinates issue.

You can use PixInsight to fix this by running ImageSolver on the file first before PCC to correct the coordinates...but you should not have to do this- the coordinates should be been correct initially. If the coordinates are not correct... should I trust the plate scale? The pixel size? Why should I trust anything in the FIts Header? (pretty mad about this! lol ) See the attached image... 

-the Blockhead

John Carter

The iCloud Drive is an Apple cloud storage. I've been able to share files and folders with other PC users with no problem. Ideally, you just click on that link and it should open up a folder in File Explorer.

Here's a Dropbox link:

https://www.dropbox.com/sh/j3bjrc0405iudnp/AAC7a7e9Q1l04edUi8C_s6-pa?dl=0

John Carter

You wrote:

This is very frustrating. I really dislike Garbage information in the header. Your coordinates are incorrect. What software is responsible for putting those coordinates in the header? 

Are you talking about the FITS header in the files? If so, that information was written by N.I.N.A., and many other files captured by N.I.N.A. work just fine. And if ASTAP can do a plate solve on those images, then why not PCC?

Here's what the FITS header shows for coordinates for the master Red file:

And those coordinates are right AFAIK

And here is the result of PCC on the combined RGB master:

* Target image: Limiting to 15 brightest stars.

Matching stars: done

*** 5 star pair matches found - need at least six matched stars.

* Previous attempt failed - this is try #10

useScaleDifferences=true

* Reference image: Limiting to 15 brightest stars.

* Target image: Limiting to 15 brightest stars.

Matching stars: done

*** 0 star pair matches found - need at least six matched stars.

* Previous attempt failed - this is try #11

useScaleDifferences=false

* Reference image: Limiting to 8 brightest stars.

* Target image: Limiting to 8 brightest stars.

Matching stars: done

*** 0 star pair matches found - need at least six matched stars.

* Previous attempt failed - this is try #12

useScaleDifferences=true

* Reference image: Limiting to 8 brightest stars.

* Target image: Limiting to 8 brightest stars.

Matching stars: done

*** 0 star pair matches found - need at least six matched stars.

*** Error: Unable to find an initial set of putative star pair matches.

*** Error: The image could not be aligned with the reference star field.

Please check the following items:

The initial coordinates should be inside the image.

The initial resolution should be within a factor of 2 from the correct value.

Adjust the star detection sensitivity parameter, so that the script can detect most of the stars in the image without mistaking noise for stars.

The catalog should be matched to the image. Choose the appropriate catalog and magnitude filter, so that the number of stars extracted from the catalog can be similar to the number of stars detected in the image.

*** Error: Unable to plate solve image: Alignment failed.

This usually happens because the initial parameters are too far from the actual metadata of the image.

** Warning: Process finished with errors:

  PCC_T_JV0LIAJQ66IY.xisf: The image could not be plate solved

*** Error: Failure to plate solve image: Image04

Reading swap files...

888.130 MiB/s

<* failed *>

And here's the result of ASTAP on the combined RGB master:

PLTSOLVD=                    T / ASTAP internal solver      

COMMENT 6  Solved in 1.5 sec. Offset was 36.7'. Mount offset RA=10.4', DEC=35.2'

WARNING = 'Warning scale was inaccurate! Set FOV=0.51d, scale=0.9", FL=1351mm &'

CONTINUE= 'Star database limit was reached!'

END                                                                             

Here's the ASTAP result for just one of the original FITS files:

PLTSOLVD=                    T / ASTAP internal solver      

COMMENT 6  Solved in 1 sec. Offset was 35.8'. Mount offset RA=, DEC=

END                                                                             

What concerns me is that N.I.N.A. has the focal length set differently:

FOCALLEN=                2737. / Effective focal length (mm)                    

So why didn't the single file plate solve return a comment about the wrong focal length?

The OTA is a C14HD:

C14:  fl=3910mm Aperture=356mm f/11

The Focal Reducer is a 0.7x:

C14 with 0.7x FR: f/7.7, fl=2737

John Carter

And if the previous Dropbox link fails, here's another:

https://www.dropbox.com/sh/vl1imgor9cb461b/AAAR3oiJh-k_tdEyLOAp6Fkta?dl=0

BlockHead

John,

Even ASTAP is telling you are you more 1/2 a degree off in pointing. 

What limit should a software have in accepting inaccurate information?

PCC, by design, is made to accept that the coordinates are in the field of view. 

I think this is a fair constraint.

ASTAP does not assume this and likely has logic to search an area greater than your input- and look what happens- you think this is the way it should be! 

So, this is the answer to your question. PixInsight is a software that for platesolving purposes requires the coordinates be in the picture. (Additionally you need to be within a factor of 2 for the plate solution).  ASTAP apparently has a looser constraint. However, this laxness has lead you to believe that it is a good and fine thing. I disagree. Inaccurate data by more than 1/2 degree and outside of your field of view is a red flag that ASTAP should be SCREAMING at you to look at. So I think you really should be venting with NINA for the garbage information and ASTAP for not telling you there is garbage to be cleaned. PixInsight if anything is being fair with its well defined constraint.

-the Blockhead

if(function rt(){return!!window.Ember||(!!window.Vue||(!!window.Meteor||(!(!window.React&&!document.querySelector("[data-reactroot], [data-reactid]"))||!!(window.angular||document.querySelector(".ng-binding, [ng-app], [data-ng-app], [ng-controller], [data-ng-controller], [ng-repeat], [data-ng-repeat]")||document.querySelector('script[src*="angular.js"], script[src*="angular.min.js"]')))))}()){window.postMessage({singlePageAppCheck:true})}else{window.postMessage({singlePageAppCheck:false})}

John Carter

I'm beginning to agree with you.

I recently changed the output file format from FITS to XISF in the N.I.N.A. software, and now none of the images I take can be plate solved with PI.

John Carter

Let's look at this again.

You are saying that the coordinates PI gets from the header are not anywhere near the center of where the object should be even though the object is centered in the field of view. Yet we can clearly see that the coordinates in the header appear to be right. So why would PI not be able to extract the right values from the XISF header while being able to extract them from a FITS header?

The developer at N.I.N.A. is pointing fingers at PI. They can find nothing wrong with the XISF header. Can you be explicit about what you say is 'gibberish'?

John Carter

A question being asked:

what metadata is it that PCC is actually using? the object coordinates, or the "center of view" coordinates?

the two can be different

BlockHead

The coordinates written in the FITS header are not correct... they are not where the telescope is pointing. Something (NINA?) is putting bad information in the header to the file when the file saved.if(function rt(){return!!window.Ember||(!!window.Vue||(!!window.Meteor||(!(!window.React&&!document.querySelector("[data-reactroot], [data-reactid]"))||!!(window.angular||document.querySelector(".ng-binding, [ng-app], [data-ng-app], [ng-controller], [data-ng-controller], [ng-repeat], [data-ng-repeat]")||document.querySelector('script[src*="angular.js"], script[src*="angular.min.js"]')))))}()){window.postMessage({singlePageAppCheck:true})}else{window.postMessage({singlePageAppCheck:false})}

We do not clearly see the coordinates in the header are correct... they are incorrect. The picture I posted earlier shows where those coordinates are... 

To be explicit... without using explicit language...

The header has coordinates RA 09 43 58  Dec +32 32 22

This is NOT where your telescope is pointing. These coordinates are more than 1/2 a degree away from your objects.

-the Blockhead

BlockHead

By the way... to prove to yourself that PCC will work...do the following:if(function rt(){return!!window.Ember||(!!window.Vue||(!!window.Meteor||(!(!window.React&&!document.querySelector("[data-reactroot], [data-reactid]"))||!!(window.angular||document.querySelector(".ng-binding, [ng-app], [data-ng-app], [ng-controller], [data-ng-controller], [ng-repeat], [data-ng-repeat]")||document.querySelector('script[src*="angular.js"], script[src*="angular.min.js"]')))))}()){window.postMessage({singlePageAppCheck:true})}else{window.postMessage({singlePageAppCheck:false})}

1. Check the box that says "Ignore Existing Metadata" Check "Force plate Solving"

2. Go to the Search Coordinates button... and in the Search field type the name of one of the galaxies (NGC 2698). This will return the actual coordinates of the galaxies which we know is in the field of view.

3. Execute PCC as normal. 

This results in success as expected. 

See my screenshot attached to this post.

-the Blockhead

John Carter

I have three different targets all doing the same thing. ASTAP plate solves, PCC doesn't. And all since I reconfigured N.I.N.A. to output to XISF.

The header information for the coordinates matches what SkySafari says it should be.

When the wind dies down, I'm going to take the same image (M109, NGC2986) with N.I.N.A. configured to output to a FITS format and see if anything changes.

It has been recommended that I do a center after drift in N.I.N.A., once I learn what that is about, and also do a sync from N.I.N.A. to the mount. So there are several changes to try, and one thing at a time.

BlockHead

I will mention something that is true...and I did not write it out before...because it is another rabbit hole.

The funny thing about answering questions in general is that (like a doctor I guess) I know so many possible issues... some common..some rare- that venturing to guess is fraught.

However, here is that true statement. One thing that is possible to do is synch the mount of a telescope and confuse software. It is also possible to synch a mount and have it point to objects properly- but not have the correct coordinates because the time/location is incorrect. You will still find objects because the relative distances are unaffected (of course) by that kind of error.

So many problems. But I want to be clear... if SkySafari is saying the coordinates of NGC 2698 is what is in the header.. it is wrong. The coordinates for NGC 2698 are precisely what is in the screenshot... which is different. 

-the Blockhead

BlockHead

By the way...do you think your example would make a good brief YouTube video illustrating the issue...and the solution?if(function rt(){return!!window.Ember||(!!window.Vue||(!!window.Meteor||(!(!window.React&&!document.querySelector("[data-reactroot], [data-reactid]"))||!!(window.angular||document.querySelector(".ng-binding, [ng-app], [data-ng-app], [ng-controller], [data-ng-controller], [ng-repeat], [data-ng-repeat]")||document.querySelector('script[src*="angular.js"], script[src*="angular.min.js"]')))))}()){window.postMessage({singlePageAppCheck:true})}else{window.postMessage({singlePageAppCheck:false})}

-the BLockhead

John Carter

I found the problem.

In N.I.N.A., I had 'Do Not Sync' enabled for the telescope.

Once I disabled that, any XISF or FITS file now works with PCC.

Sorry.

BlockHead

John,

Do you think this would make a good instructional video?

I think there is an awful lot to learn here... and likely others can benefit.

What do you think?

-the Blockhead

John Carter

Well, since the PCC problem was caused by an improper setting in N.I.N.A. and nothing to do with PI, can you elaborate on how this could benefit others to know about the settings in N.I.N.A.?

I'm sure this happened when I totally deleted N.I.N.A. and started from scratch. Since I didn't record the settings from the previous usage, I was taking a guess about whether or not I needed to allow N.I.N.A. to sync to the telescope. My concern was that it would override any model that I had previously set up. It doesn't, as I found out.

When I use PCC on my images, it makes no noticeable visual difference to the image when blinking between a before and after.

N.I.N.A. is so good with its new three star Polar Align, and with its slew and center (with the help of ASTAP). Just since using N.I.N.A.'s Polar Align procedure, my tracking with PHD2 has been phenomenal. All of my previous attempts to achieve good tracking just wasted my time. And despite all the strong recommendations to do drift align, that's never been needed. Current guiding error is +/- 0.25", and I really don't care to try to get it any better than that. Anytime the error goes out beyond that is due to a gust of wind.

What I'm still struggling with is getting good color in stars. All of my images are OSC, so I don't have the luxury of using filters (and I really don't want to). I recently did two sets of images at different exposures of M42 (10s and 2s) to see if blending in the lower exposure set would help with star color.

The other issue I'm having is with gradient and background removal. Following your Fundamentals course doesn't seem to help. After calibrating and stacking in PI, it seems I can better results with a few simple adjustments by turning over the image to Affinity Photo. I'm sure I'm tossing out the baby with the bathwater (would get much better images if I learned how to use PI).