Apologies for going off topic. But yes, I was referring to Canon CR2/CR3, and Nikon NEF. I image in native format because it's an easier workflow as it is compatible with darks and bias captured in camera without ekos. Currently I have to make a point of saving a FITS image to use later as a realignment frame.

Yes, support for Canon CR2 would be fine, if this could be integrated sometime in the future.

About tiff-support. I can solve my tiff-pics without problems. The only thing is, that for opening the tiffs in the align-module in kstars, you must delete the Filter "images" in the opening dialog

btw. It looks like the astrometry.cfg is not needed anymore now. Thanks for fixing this.

For me, downsampling (from1 to 5) does not work at all, I will leave this unchecked.
The message "Solver Failed" came very fast each time.

But from my perspective, the new downsampling code is responsible for a crash when I try to solve M65. This was the fits file that previously caused no problem at all.

TheSkyX uses sextractor. In case this is helpful, these are the settings both of my rigs use, one is a cadiotrope, the other is a reflector refractor.

Very helpful, thank you!

Welcome!
Caught a typo - those TSX settings work with both my cadiotrope (corrected dall-kirkham) and refractor (FSQ106).

I corrected a couple of things today. I finally got rid of those pesky messages that were being printed out to the console by the internal astrometry. I also corrected an issue with scale if you aren't using arc seconds per pix for the units. I also improved the logic for what happens when the solvers complete, which might make it stabler when it is doing a lot of operations. Please let me know if these changes help.

I think this might solve some issues where it failed to solve due to the scale

I will next take a good look at the parameters that folks have shared recently as well as what was hard coded in kstars to see if we can improve the profiles more.

Rob,

Is it possible the system parameters can be discovered through training on a set of data from the optics/camera in use? Perhaps make a tool that consumes a set of data and establishes a custom profile?

- Greg

Hi Rob,

I've tried again the focalmm scale mode with the stacked image I've sent some days ago. It doesn't crash now, but it can't solve yet the image

The value for the arcsec/pixel seems wrong to me. For the 600mm focal length on my telescope and 5.70 microns per pixel, the image scale is 1.975 arcsec/pixel well outside the searched range

HI, is that this image?



I got it to solve with a blind solve. Did you say that it has focal mm info in it, or did you enter the scale in focal mm yourself to test it? As far as I can tell there is no position or scale information in the file.

I can definitely check the scale mm calculation. Usually images don't come with that scale information, they are usually in arc seconds per pix. So it probably hasn't been tested much yet.

I just investigated a little bit. The focal mm scale is not as simple as just entering your focal length.

So from what I found in a google search, that parameter is supposed to be:

"35-mm (width-based) equivalent focal length"

The calculation in astrometry.net code for converting this to arc seconds per pixel is pretty much this:

(Arc Sec Per Pix High) = rad2arcsec(atan(36 / (2 * (SCALE LOW)))) / (IMAGE WIDTH);
(Arc Sec Per Pix Low) = rad2arcsec(atan(36 / (2 * (SCALE HIGH)))) / (IMAGE WIDTH);

There is also a note in there that "35 mm" film is 36 mm wide.

So based on this information, if we have an image with a certain width, to enter the scale information for your image in order to solve it, we may need to know how wide your sensor is in MM so that we can figure out how that compares to 36mm. Then we can multiply your actual focal length by that scale factor to estimate what the scale should be.