Regarding the ZWO ASI driver.
Manual says "supports region of interest". Is this implemented by the "frame" settings in the control panel? No way to, say, select an area in a test photo as with the focusing module?
What is "rapid looping" in the control panel "options" settings? Is it related to the count/delay settings under the Ekos CCD tab?
So to take hundreds of exposures of a small object as economically as possible, one places it within the numerical coordinates entered in the frame settings (either in the driver control panel or Ekos CCD tab) and configures rapid looping in the control pattern or count/delay under the Ekos CCD tab?
Last night I tried to run plate solver from my DIY push-to telescope, but I was unsuccessful. Instead an alert popped up saying telescope aperture and focal length needed to be entered.
How does one do this?
I have found a place to enter aperture and focal length under "settings -> configure observation logging -> list your equipment" but this doesn't seem right, (and I cannot check until next observing session). The FAQ mentions a "profile page" but I can't seem to find that. Finally, when starting EKOS, there is a message in the logging window that a config file was looked for but not found.
What am I missing?
Still running version 2.6.0 from Debian stable, Stretch. (am willing to upgrade to testing)
My camera is a ZWO ASI290MM which should be producing 12 bit per pixel output. So, in analogy to DSLR output, I expected the FItS data to be an array of positive integers between 0 and 2^12-1 = 4095 with min and max nested between those extremes. But when I look at the data table of a photograph, FITS header attached, the values are all positive integers, *but* they are all even numbers and they top out at 5232. Min is around 160. Then the values for DATAMIN and DATAMAX are -898.34... and 5231.76.... I would like to understand how those numbers are obtained. It can't be a linear transformation a*x+b where a and b are scale and offset because any such number should be an integer if x is, so I guess there is some other algorithm.
Don't mean to be bothersome. Thanks.
I don't understand how DATAMIN and DATAMAX in the FITS header are derived from the data. When I look at the data table in FV, all the entries are positive integers, but the header entries for DATAMIN and DATAMAX are by definition double precision decimals. How to get from one to the other?
So far I have found the function getMinMax in indiccd.cpp which is simple enough routine for finding extreme values. So I guess the float values come from the function getFrameBuffer for which I have not yet seen the source but will look for. But until then, I'm wondering what could be the reason to use decimal fractions to represent extreme values of binary integers?
Your suspicion is correct. The image is clearly there. See attached screenshot. Thank you very much.
This is a continuation of my two previous posts with new data. Hope I'm not too pesky.
Last night I was trying to capture Struve 2797 in Peg on camera. As before, I needed to reduce exposure time to split A and B. I succeeded according the Kstars FITS viewer preview. But the preview was saved to file, the star disappeared.
Attached are two screenshots.
One of the Kstars FITS viewer preview. The split is not visible here as clouds rolled in while I was working this image, but you can clearly see the star above the noise.
The other screenshot shows the saved file in the same viewer. Nothing there. Nada.
I'll attach the FITS header as well.
Is this a bug? I don't see anything related in the bug tracker, but I don't see much activity there either.
I also observed the following related behavior. I was photographing M15 just before Struve 2797. The FITS viewer would present the image that was exposed for 1 second and saved in 8 bit format. Very low dynamic range but visible nonetheless. Then when the exposure was reduced to .2", the saved image was completely blank. However, when the same exposure was saved in 16 bit format, a visible image was recorded. This was why I was saving the STT 2797 in 16 bit format. But even then the image was lost at very short exposures.
I have another exposure, this one pointed at (or near! (no go-to)) a cluster (M15), exposed for 5" with gain set to 540. Here the maximum recorded pixel value is 109.
So this camera with Ekos *can* produce higher pixel values.
But this still really bothers me.
There are 14,663 pixels with value 109. And there are only 6232 pixels with value 100-108. Visually, even the smallest stars contain pixels with value 109.
Why would so many values be recorded at the maximum? I was expecting a smooth tail like a bell curve (or binomial distribution).
I'd be glad to post additional data in some form if anyone would like.
I didn't know until now, but fv the fits file viewer is helpful.
The image I posted was .5" exposure of STF 12 in Pisces with magnitudes 6.1 and 7.5. The FITS data are all positive integers < 2^2.
Now I have an image of the "double double" in Lyra, magnitudes 5.2 and 6.1, only this time with .05" exposure and gain set to 200. In this case FITS data are all positive integers < 2^3, or 3 bit data. Please see the text attachment. Strange how there are 22 "7"s in a row. That is, if the data is 3 bit only because of the low light, strange that there would be so many maxed pixels in a row.
File Attachment:File Name: eps_sample_row.txt
File Size: 0 KB
I have other images whose preview clearly showed stars but which upon saving consist of an array of 0's only.
So I'm wondering, what determines the bit depth of the data that is actually saved to file?
Thanks for reading.
I am doing something dreadfully wrong.
Here is my image of a double star in Pisces. Taken by clicking "set" at .5" in the Main Control panel. Gain set to 0. No other changes from default.
Why only 2 shades of gray?
sometimes, when there is an image in the Kstars viewer that I want to save, I select "File > Save" and choose a file name (.fits is automatically appended). But when I come back later and open the file, there is nothing there, only a blank gray screen (heartbreaking). The FITS header shows the correct exposure. The information bar along the bottom of the viewer shows the full complement of pixels. It's just that the double star that I had captured according to the viewer has disappeared.
several times I came back and re-took the image and overwrote the file with "File > SaveAs" successfully, but the times I forgot to check, I just lost the image.
Am I doing something wrong? I can't seem to find any record of anyone having a similar experience.
Thanks for response. Looks like KStars 2.9.8 is available in Debian 10. I'll give that a go.
seems like I lost a post. sorry for any redundancy. i took some screenshots this time though.
Kstars version 2.6.0 release 16-08-3, stock with Debian 9.
I wasn't able before but now the control panel will accept exposure of, say 10^-4 seconds and it works as it should. I expected it to reflect in first window but now it doesn't. Please see screenshot.
But in other locations, only 3 decimal places are accepted: streaming and in ccd & filter taps in Ekos. Again see screenshot.
Is this the way one should expect?
Thanks for responses.
The ZWO website specs for the ASI 290MM camera lists the shortest exposure as 32 microseconds. However, the minimum accepted exposure in Ekos for this camera is 1 millisecond.
Is this a hard limit? or is there a way to get exposure below 0.001 second?