This question is old, but:
ASTAP will convert batch-wise between FITS and Astro-TIFF and backwards. See viewer under Tools, batch processing.

Han

Read More...

The Astrometry.net solver gives you only the four CD keyword for the solution orientation and scale (plus the reference pixel CRPIX1, CRPIX2 and position CRVAL1, CRVAL2) . They provide all the information. If you use them why can't do the same with ASTAP? Then fix all discrepancies. All solvers give you the correct and same solution. But you have to process at least two header keywords and not just one for orientation.

Stellar solver is using the Astrometry,net code. I don't know what Robert did for additional processing for orientation. Hopefully he can clarify this. But to standardize you better move/copy his code line which is a function(CD1_1, CD1_2, CD2_1, CD2_2) to Ekos and use it for all solvers. Then there will be no discrepancies.


Note:
The reason CROTA2 changed in ASTAP is that for flipped images it was wrong for the classic solution keywords (CROTA1, CROTA2, CDELT1, CDELT2). To simulate the old situation it would in principle require a new keyword something like ANGLE because I don't want to ASTAP to produce wrong classic keyword solutions. Since Astrometry.net doesn't provide any angle directly (the classic keywords are missing) it was much better and elegant to refer to the modern CD keywords. So the suggestion is just to use them and ignore CROTA2.


Han

Read More...

About the orientation reported by nova.astrometry.net. This one is dependent on the type of image. The same image uploaded as PNG or FITS results in a 180 degrees different reported. I have reported this a bug but the Astrometry.net team is not interested in correcting it. They say the solution in CD1_1...keywords is correct. That is correct. The problem lies in the angle reported in the online report. Not in the header solution.

The bug report is changed to feature request:
github.com/dstndstn/astrometry.net/issues/151

Han

Read More...


If you flip a transparent image also the visible orientation will flip. However the actual orientation in the sky can not be flipped. Any inverting telescope or camera does not change the orientation in the sky so the angle is better reported unflipped.


The CROTA2 is only part of the solution. In is a pair with CDELTA2. You can't specify the orientation of an image with one value like CROTA2. You need two values.

If you want an uniform report by all solvers, then you should use something like this:
if (cd1_1*cd2_2-cd1_2*cd2_1)>=0 then sign:=+1 else sign:=-1;
rotation:= -arctan2(cd2_1,sign*cd1_1)*180/pi; //arctan2 returns arctangent of (y/x)

See www.hnsky.org/astap.htm#viewer_angle

Han




Read More...

han shared a photo. 2 years ago

ASTAP crashed in these files when it tries to change a header keyword. But it is now avoided in ASTAP version 2022.09.16. But the Ekos/Indi files are still not conform the FITS standard.

I'm not familiar with Ekos/Indi bug/issue tracker but raised an issue here
github.com/indilib/indi/issues/1733

Han

Read More...

INDIGO has implemented Astro-TIFF is the code.

Read More...

Good. I looked it briefly up for somebody and could only find: Compression = 32946 PKZIP-style Deflate encoding (experimental)

which accordiing Wikpedia is different the compression type=8 Deflate. But the documentations for the coverage hasn't been updated since 2002. :)

Read More...