Hello Jasem,

The images came from an user. I haven't Ekos running here. The LibRaw program raw_identify gives this:

raw-identify -v  ./2.CR2
.....
Number of raw images: 1
Thumb size:  5184 x 3456
Full size:   5344 x 3516
Raw inset, width x height: 5184 x 3456 left: 152 top: 56
Aspect: 3:2
Image size:  5202 x 3464
Output size: 3464 x 5202
Image flip: 6
Canon record mode: 6, CR2
SensorWidth          = 5344
SensorHeight         = 3516
SensorLeftBorder     = 152
SensorTopBorder      = 56
SensorRightBorder    = 5335
SensorBottomBorder   = 3511
Margins cropped active area: left=168, top=56
.....

So you can identify:

Raw size: 5360x3516
Active area size: 5202x3464
Default cropped active area: 5184x3456
Margins active area: left=158, top=52
Margins cropped active area: left=168, top=56

So there are 5202 - 5184= 18 pixels spare in width
So there are 3464 - 3456= 8 pixels spare height.

The left-top coroner of the 5184x3456 frame is at position 168, 56.  The Ekos left-top corner of the 5184x3456 frame is at 158, 51?
The left-top coroner of the 5202x3464 frame is at position 158, 52

You have to read S.raw_inset_crops[0].cleft and S.raw_inset_crops[0].ctop  to be correct.

Han





 

Read More...

The offset for the cropped-active-sensor-area (Thumb) are reported in the LibRaw sample program raw_identfy.cpp as follows:if (S.raw_inset_crops[0].cleft != 0xffff)fprintf(outfile, "left: %d ", S.raw_inset_crops[0].cleft);if (S.raw_inset_crops[0].ctop != 0xffff)fprintf(outfile, "top: %d", S.raw_inset_crops[0].ctop);

Some format like .PEF don't report these values. Same for "thumb size" dimensions  (Strange name only used in DCRAW and LibRaw.)

But is better to extract the whole-active-sensor-area.(Image size). Why throw away active pixels?

Read More...

Easiest fix would be to extract always the full active sensor area. In this case 5202x3464 pixels. Extracting the default cropped active area, 5184x3456 pixels is just a waste. You have to crop the image later anyhow. That is also what other programs (MaximDl, SGP) are doing.

Some background info about the sensor areas can be found here:
www.barrypearson.co.uk/articles/dng/specification.htm#areas

Han

Read More...

The images produced by Ekos are shifted 10 pixels in width en 5 pixel in height compared with Adobe Digital Photo Professional and ASTAP.  This is not a major problem but doesn't allow the make darks outside Ekos.

I have compared hotpixels from FITS images taken with Ekos/Astroberry with CR2 darks and analysed them with Adobe Digital Photo Professional and ASTAP 1.0.0RC2. All images are in 5184 x3456 pixel format These are the positions of two hotpixelsCR2 dark using DPP (Adobe), positions 18, 3141 and 152, 2802 (counting starts at zero)
CR2 dark using ASTAP, positions: 19, 3142 and 153, 2803
FITS light by INDI, positions: 29, 2147 and 163, 2808So there is a shift of 10 in width and 5 in height between the INDI FITS and the CR2 dark. The fault lies in Ekos/INDI. For ASTAP the position of the .CR2 hot pixels are exactly the same as with Canon "Digital Photo Professional". For INDI FITS file the extracted 5184 x3456  cropped-active-area  lies not in the middle of the full-active-area of 5202x3464 pixels but at the side. In Libraw the left and right margin of the cropped active area (thumb) are defined  S.raw_inset_crops[0].cleft and  S.raw_inset_crops[0].ctop and have the values for the tested image 168, 56 pixels. The margins for the active area are left 158, top=52. The difference is the same 10 and 5 pixels.

I have idea where to place a bug report. Maybe somebody can do that.

Han

Raw size: 5360x3516
Active area size: 5202x3464
Default cropped active area: 5184x3456
Margins active area: left=158, top=52
Margins cropped active area: left=168, top=56

  • A + C:   The Active Area, which is the largest area from which a useful image can be formed.
  • C:   The Crop Area, which is the subset of the Active Area which many raw converters convert into a useful image. The main reason why C is smaller than A is to provide some extra pixels all around for a raw converter's demosaicing algorithm to use.
  • :  Masked Area, used by some cameras, especially Canons used a dark.
 
 


Read More...

han replied to the topic 'Dither messes up guide exposure' in the forum. 6 months ago

I have asked the creator of StellarSolver, (Rob) for assistance and he thinks it a problem of Ekos. If he has time he is willing to look into it. I can't do much. At the moment I don't even know where to find the bug tracker of Ekos.

Han
author of ASTAP

Read More...

han replied to the topic 'ASTAP/KStars issue (with workaround)' in the forum. 7 months ago

Hello Hy,

Why there would be a difference in execution speed, I can only guess. Maybe FOV setting is lower.  It will still solve if the FOV is 20 to 30 % too low but less reliable and reduces the speed. As you already mentioned, ASTAP requires the image height in degrees. If it is unknown you could execute it with "-fov 0"  which is equivalent to auto and it will try all FOV's between 10 degrees and 0.4 degree but I'm not sure if that is possible with EKOS.  The program SharpCap uses this option in case solving fails, but I think it is better reserved for once during installation or images with no FOV specified.

ASTAP can be used as star extractor using the the option -extract , see www.hnsky.org/astap.htm#astap_command_line   You only have to specify the minimum star SNR  For solving specify minimum snr  as 10. (-extract 10). The output is a csv text file.

Note ASTAP is now also available as a command line executable version for headless setups.

Han

Read More...

han replied to the topic 'ASTAP/KStars issue (with workaround)' in the forum. 7 months ago

Maybe this is something for Rob, @ rlancaste

Han

Read More...

You can just download the Debian package for armhf (32bit) and arm64 (64 bit). No compilation required. If you want to compile, install Lazarus and load astap_linux.lpi then compile.

Binaries
64 bit:
sourceforge.net/projects/astap-program/f...p_arm64.deb/download

32 bit:
sourceforge.net/projects/astap-program/f...p_armhf.deb/download


You can associate it to .fits or for quick scrolling you have this option:



Han

Read More...

Binning prior to the file exchange with ASTAP will be the fastest solution. Saving and loading a binned image is much faster then with the original size.

Read More...

Yes that looks okay to me. You delegate all binning to ASTAP. However I assume you get a shorter execution time if the binning is done is Ekos so the file size is smaller from the beginning. So if possible it is faster to bin earlier in Ekos avoiding disk read/write time.

Han

Read More...

Hello Rob,

Looks all good and complete for messages. Just add -z 0 to the command line as a safeguard/override against ASTAP internal settings.



p.s. I'm working on a new database format for ASTAP splitting it in smaller sections to speed up solving. At the moment no idea how effective that will be. It will have no effect the interface. An other option is using multiple processors but at the moment no desire to go that way.

Han

Read More...

Hello Rob,

See my remarks:

rlancaste wrote: Hi Hank,
1. So I was thinking that both SEP and local Sextractor were working pretty well with ASTAP, are you saying that the built in star extraction should be preferred with ASTAP, or are you saying that the other methods don't work with ASTAP.


In august I decided to remove the .XYLS input. I was not so happy with the "cleanness" of the code and the internal ASTAP extractor performs very similar, so I removed the option to use sextractor as indicated here:
www.indilib.org/forum/general/6845-new-i...html?start=288#58378

rlancaste wrote: Hi Hank,
2. I am not sure what you mean by "part of the log is missing". Are you saying the log information is not getting into the Ekos log at the bottom of the Align Module or are you saying that it isn't appearing in a log file?
Of the ASTAP log only the first line is reported in Astrometrylog.txt. The next line line "using


Of the ASTAP log only the first line is reported in Astrometrylog.txt. The next line lines "using G17..." are not reported in AstrometryLog.txt. See red marked part of the log.

rlancaste wrote: Hi Hank,
3. The search radius can easily be set in the Options Profile, along with many other options. The default for all the profiles is 15 degrees, but can easily be changed by the user.

Good, I missed that.

rlancaste wrote: Hi Hank,
4. For downsampling, currently I have it using the downsample option selected by the user in the options profile. There is also an auto downsample option. So you are saying here that if the user has the auto downsample option selected, then we should still pass the z parameter with a "0", since currently we only pass the parameter if they have something other than 1 selected. Or am I misunderstanding this?

The downsampling can be set in Ekos. That is good no change required. Adding the extra option : "-z 0" prevents that ASTAP does a second additional binning. It is the safest option for the case the user accessed ASTAP directly and forced a binning=2x2 in the ASTAP settings.

rlancaste wrote: Hi Hank,
5. We can definitely process the warnings, that should not be too hard. I will be sure to do that. But are you meaning that the information should be displayed in the log at the bottom of the Align module or in a separate log file?
For the idea of displaying information as discussed in #2 and #5, we do have options in KStars for the user to be able to decide whether they want to display the information in a separate log file, if they want everything to be displayed at the bottom in the Align module, and if they want to save all that to a combined log file. I am just asking to clarify what you meant about what you said.

The ASTAP warning(s) are useful since it warns the user of incorrect pixel-scale/focal length which could result in a poorer performance. The ASTAP log contains all warnings and error messages. That is probably the easiest solution. Alternatively you could read the program exit code for ERROR or the keywords WARNING or ERROR of the ini file or the WARNING keyword of the .wcs file.

I would prefer to have at least the warning implemented so either read the full log or read the string behind the "WARNING =" keyword in the .wcs file are the easiest way to implement.

Cheers, Han

Read More...