×

INDI Library v2.0.7 is Released (01 Apr 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
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 6 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 6 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 6 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 6 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 6 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 6 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 6 months ago by Jose Corazon.
3 years 6 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 6 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 6 months ago #61676
Attachments:

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

  • Posts: 61
  • Thank you received: 10

I tried to narrow down the error: "Astrometry configuration file corrupted or missing ..." which happens, when I install kstars without external astrometry.net.

All happens in ksutils.cpp

The error is created in this function:
QStringList getAstrometryDataDirs()
{
    QStringList dataDirs;
    QString confPath = KSUtils::getAstrometryConfFilePath();
 
    QFile confFile(confPath);
 
    if (confFile.open(QIODevice::ReadOnly) == false)
    {
        bool confFileExists = false;
        if(Options::astrometryConfFileIsInternal())
        {
            if(KSUtils::configureLocalAstrometryConfIfNecessary())
            {
                if (confFile.open(QIODevice::ReadOnly))
                    confFileExists = true;
            }
        }
        if(!confFileExists)
        {
            KSNotification::error(i18n("Astrometry configuration file corrupted or missing: %1\nPlease set the "
                                       "configuration file full path in INDI options.",
                                       confPath));
            return dataDirs;
        }

This in the function shows "false", so "confFileExists" cannot become true ---> that´s why the error appeares..
if(KSUtils::configureLocalAstrometryConfIfNecessary())


This is the function "configureLocalAstrometryConfIfNecessary()"
//Note maybe the Mac and Linux versions of creating the local astrometry conf file and index file folder can be merged.
//I moved both of them here and this method references each one separately.
//One is createLocalAstrometryConf and the other is configureAstrometry
bool configureLocalAstrometryConfIfNecessary()
{
#if defined(Q_OS_LINUX)
    QString confPath = KSPaths::writableLocation(QStandardPaths::GenericDataLocation) + QLatin1String("astrometry") +
                       QLatin1String("/astrometry.cfg");
    if (QFileInfo(confPath).exists() == false)
    {
 
        if(createLocalAstrometryConf() == false)
            return false;
    }
#elif defined(Q_OS_OSX)
    if(configureAstrometry() == false)
    {
        KMessageBox::information(
            nullptr,
            i18n(
                "Failed to properly configure astrometry config file.  Please click the options button in the lower right of the Astrometry Tab in Ekos to correct your settings.  Then try starting Ekos again."),
            i18n("Astrometry Config File Error"), "astrometry_configuration_failure_warning");
        return false;
    }
#endif
    return true;
}

I´m looking in the Linux-Section of the function and find this showing "false". That´s why "configureLocalAstrometryConfIfNecessary()" returns "false"
if(createLocalAstrometryConf() == false)

That´s the function "createLocalAstrometryConf()"
//Can this and the mac method be merged somehow?  See KSUtils::configureAstrometry.
bool createLocalAstrometryConf()
{
    bool rc = false;
 
    QString confPath = KSPaths::writableLocation(QStandardPaths::GenericDataLocation) + QLatin1String("astrometry") +
                       QLatin1String("/astrometry.cfg");
    QString systemConfPath = "/etc/astrometry.cfg";
 
    // Check if directory already exists, if it doesn't create one
    QDir writableDir(KSPaths::writableLocation(QStandardPaths::GenericDataLocation) + QLatin1String("astrometry"));
    if (writableDir.exists() == false)
    {
        rc = writableDir.mkdir(KSPaths::writableLocation(QStandardPaths::GenericDataLocation) + QLatin1String("astrometry"));
 
        if (rc == false)
        {
            qCCritical(KSTARS) << "Failed to create local astrometry directory";
            return false;
        }
    }
 
    // Now copy system astrometry.cfg to local directory
    rc = QFile(systemConfPath).copy(confPath);
 
    if (rc == false)
    {
        qCCritical(KSTARS) << "Failed to copy" << systemConfPath << "to" << confPath;
        return false;
    }
 
    QFile localConf(confPath);
 
    // Open file and add our own path to it
    if (localConf.open(QFile::ReadWrite))
    {
        QString all = localConf.readAll();
        QStringList lines = all.split("\n");
        for (int i = 0; i < lines.count(); i++)
        {
            if (lines[i].startsWith("add_path"))
            {
                lines.insert(i + 1, QString("add_path %1astrometry").arg(KSPaths::writableLocation(QStandardPaths::GenericDataLocation)));
                break;
            }
        }
 
        // Clear contents
        localConf.resize(0);
 
        // Now write back all the lines including our own inserted above
        QTextStream out(&localConf);
        for(const QString &line : lines)
            out << line << '\n';
        localConf.close();
        return true;
    }
 
    qCCritical(KSTARS) << "Failed to open local astrometry config" << confPath;
    return false;
}    }


Looks like the problem in this function is located here;
// Now copy system astrometry.cfg to local directory
    rc = QFile(systemConfPath).copy(confPath);
 
    if (rc == false)
    {
        qCCritical(KSTARS) << "Failed to copy" << systemConfPath << "to" << confPath;
        return false;

Since I have no astrometry.net-program installed, there is no astrometry.cfg to copy. And the functuon returns with "false". It never can become "true"

Maybe this helps a bit, fixing this bug
3 years 6 months ago #61703

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

  • Posts: 91
  • Thank you received: 18
great work on the new solver! I built from git source master branch on ubuntu 20.04 and ran tests
on
- regular subs captured in kstars
- blind solves on sril stacked and processed versions of same targets (32 bit float .fit)
- blind solves of siril stacks further processed in gimp (.jpg)
I can't get the star circle overlays to appear but FWIW attached are my test results.
As expected, blind solves take a bit longer but none stumped the tester. Looking forward
to having this available in SM OS release ... very fast solves on all my subs !!!
Images taken with WO GT71 with FlatA6III FR/FF (336 mm FL) and ASI385MC-cool camera (3.75 um pix size).
It would be cool to be able to click a row in the star table and have that star highlighted either with a
glyph or have the annotation details pop up beside it.

File Attachment:

File Name: stellarsol...0-15.zip
File Size:2 KB
Last edit: 3 years 6 months ago by Dean.
3 years 6 months ago #61704
Attachments:

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

  • Posts: 2877
  • Thank you received: 812
Hi Edgar,

You are 100% correct, now that we have stellarsolver, astrometry.net is no longer absolutely required (though it is still nice to have) so there is no need to check or require the astrometry folders or config file. In fact, even for using external astrometry.net, stellarsolver can create its own config file for the solver to use and so doesn't need astrometry.cfg. I am sorry we haven't gotten to this yet, since we were making sure that there were not crashes and that images were properly being solved first, but we really need to tackle this soon.

Thanks for the reminder,

Rob
3 years 6 months ago #61706

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

Time to create page: 2.198 seconds