×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

  • Posts: 219
  • Thank you received: 41

I've pulled down three hours ago, but nothing new was on the repo.
3 years 5 months ago #61653

Please Log in or Create an account to join the conversation.

  • Posts: 106
  • Thank you received: 4
The reported scale range remains between 0.638705 to 0.780639 arcsec/pixel though I found in align.cpp the function definition

void Align::calculateFOV()

where I changed the values from 0.9 to 0.7 and from 1.1 to 1.3

if (opsAstrometry->kcfg_AstrometryUseImageScale->isChecked())
{
// code
else
{
opsAstrometry->kcfg_AstrometryImageScaleLow->setValue(fov_pixscale * 0.7);
opsAstrometry->kcfg_AstrometryImageScaleHigh->setValue(fov_pixscale * 1.3);

// 10% boundary
Options::setAstrometryImageScaleLow(fov_pixscale * 0.7);
Options::setAstrometryImageScaleHigh(fov_pixscale * 1.3);
}

Is it possible to give the user the option to extend the range instead of hardcoding those (arbitrary?) values? Or better: is it possible to calculate the range before the solver runs?
Powered by

GNU / Linux
Git
KDE neon
KStars | EKOS | INDI

and some cheap hardware
3 years 5 months ago #61655

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182


Not within the capture module. There never is a need to do that.

Of course, when I check guiding i am looking at an image from the guide scope, but that does not involve “changing “.

Also note that the pixel size and sensor temperature in both FITS files match my imaging scope, only the focal lengths differ.

The only place where that could happen is in the mount tab, but that would have to be changed and reversed manually, which definitely I did NOT do.
3 years 5 months ago #61656

Please Log in or Create an account to join the conversation.

  • Posts: 219
  • Thank you received: 41
No with the capture or the guide module. I was talking about the align module, the one where we perform the platesolving. Here I’ve been changing between FL and when done, sometimes the FL is mixed up on the final images generated by the capture module.
3 years 5 months ago #61657

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
I have made the mistake before that in the solver i had selected the guide scope for polar alignment and forgot to reverse that before solving my target. And yes, I know that the solver fails then. That is an obvious mistake on my part. But I have never seen that happen in the Capture module and besides, there never is a need to change the camera there to the guide cam,

Somehow, Ekos did that.

Pretty sneaky!!!
3 years 5 months ago #61658

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182


Now THAT is exactly what happened, except for one thing: I did not use the guide cam for solving, not as far as I can remember. But I cannot rule out that I used it for rechecking the PA (double checking on my pole master),

Nonetheless, I don’t understand how or why that should translate into the capture module.
3 years 5 months ago #61660

Please Log in or Create an account to join the conversation.

  • Posts: 106
  • Thank you received: 4

I changed the Scale Property in the fits header to 0.63 and the fits file was solved in seconds. So it seems to be vital that EKOS does it's best to record this property correct.
Powered by

GNU / Linux
Git
KDE neon
KStars | EKOS | INDI

and some cheap hardware
3 years 5 months ago #61661

Please Log in or Create an account to join the conversation.

  • Posts: 106
  • Thank you received: 4

I would like to add for consideration that it is not unlikely that the user checks the alignment with the guide camera. I have done this in the past because the scope is slow (f ration 13.9) and I use a light pollution filter. To see some stars with the main camera could take 40 seconds whereas the guidescope makes a fine instrument to align the mount roughly with the sky.

But the lights are still taken with the main camera.
Powered by

GNU / Linux
Git
KDE neon
KStars | EKOS | INDI

and some cheap hardware
3 years 5 months ago #61662

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182


As I wrote in response to Rafa, I cannot exclude that I forgot to change the scope back to Primary after rechecking my PA with the Guide scope.

But that mistake should never carry over into the capture module and the FITS header ( where all other parameters are recorded correctly! I would call that a bug.
3 years 5 months ago #61663

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182


Let me backpedal on that. I think I can rule that out: Reason being that IF I had forgotten to switch the align module back to Primary camera, that frame in question, showing the wrong image scale, would never have been captured. Because I never used the Capture module in isolation to acquire that frame. My workflow is to put the coordinates into the scheduler, then start the scheduler, which would have had to go through the alignment step to reach that target. And that alignment would have failed, if the wrong imaging scope was selected there. I know that for certain, because the axes of my main telescope and the guide scope are not perfectly aligned, so the Nebula would have not been centered in the final image. Yet, it is perfectly centered, exactly as I had specified, so the alignment was done with the primary imaging scope and camera.

Nonetheless, it makes no sense for the Capture module to interrogate the solver to record the image scale. Should it not rather use the Control Panel to do that? The cameras get almost never switched out from the telescope they are attached to halfway through an imaging run, whereas alignment can easily be alternated between guide cam, polemaster and main imaging camera, as Cerro also wrote.
Last edit: 3 years 5 months ago by Jose Corazon.
3 years 5 months ago #61664

Please Log in or Create an account to join the conversation.

So a couple of changes:
1. Capture module will confirm that you need to image with primary scope if it detects guide scope is active.
2. Search range extended from 0.8 to 1.2
3. Robert suggested we perform a blind solve if the regular solve fails, so this could cover it.
4. Effective Focal length and Ratio are added. I will try to make this highlight if there big differences between the scope's focal length and the effective focal length as calculated from astrometry.
The following user(s) said Thank You: Jose Corazon, Heiko
3 years 5 months ago #61669

Please Log in or Create an account to join the conversation.

  • Posts: 106
  • Thank you received: 4

You really know this code!
All files are solved now; these are my settings:



Should be useful, regarding the fact that a wrong scale factor screws it up and a non existing one is no obstacle.

The fits header of the light frame should contain the correct scale.

Nice, I love numbers.
Powered by

GNU / Linux
Git
KDE neon
KStars | EKOS | INDI

and some cheap hardware
3 years 5 months ago #61676
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 0.586 seconds