ZWO SeeStar S30
Sections in this page
I am delighted to have obtained one of these amazing little smart telescopes. I gave up astrophotography a few years ago due to arthritic knees. But this device is easy to move and controllable from indoors so I may be getting back into it. At 55°N night skies are not very good until August but I have been getting a series of Sun shots - so easy with the supplied Sun filter (seen here, in the orange ring).
I am finding that I have to recalibrate the S30's internal compass at the start of every session. Perhaps this is because I always put it back in its smart carrying case and that means it is moved about while on its side.
File names
The S30 creates image files with names that are long numbers. Unlike my smartphone the numbers do not immediately appear to show the date and time of exposure. In fact the numbers are "JavaScript time" - the number of milliseconds since the start of the year 1970 (UT). Like Julian Days this enables a simple ordering of observations without the complications of Gregorian or other calendars.
Paste such a file name into this field (with or without the dot and extension) and click the button to get JD and Gregorian date/time:
Sunspots over a few days
First deep sky attempts
M53 globular cluster
M64 the Black Eye galaxy
Amazingly these were taken through a double-glazed window and with an almost Full Moon, on the night of 2025 May 9 - 10. About 40 minutes worth of 10s exposures each.
My main purpose was to get some SeeStar FITS files to examine. I have now modified GRIP (my image processor) to recognise these files and I am working on interpreting the raw data. The FITS headers show how the Bayer filter pattern is arranged. GRIP's logarithmic histogram is proving useful for identifying singular pixels. A new version of GRIP may be available soon.
The header information (metadata) in FITS files is plain text so it is possible to see it by opening such files in a good text editor, such as Notepad++. GRIP provides a better formatted view though: File/Open image and then Image/Show image information.
Processing the raw data
SeeStar saves 3 files for each exposed frame: a FITS file, a JPEG and a thumbnail version of the JPEG. The JPEG files have been processed to be in colour and brighter than the raw data.
The first FITS file for the M53 image above has the name
Light_M 53_10.0s_IRCUT_20250509-220714.fit
which reveals several things about it. All of the FITS file names start with "Light". They are light frames. There are no flat, dark or offset/bias frames saved. That implies that those other kinds of frames have already been applied - the saved data are not exactly raw.
I have confirmed that flat frames must have been applied. By photographing a white card in Scenery Mode, it is easy to see that there is significant optical vignetting that is not present in the saved files:
I guess that internally the S30 has a saved flat frame made during production. Bias/offset values would also be known at production time. I can see periods during image acquisition when dark frames are being taken - these cannot be fixed beforehand because they are temperature-dependent (and the FITS files do record sensor temperature).
GRIP's histogram of the full FITS image is like this:
The peaks at the left of the histogram are due to pixels in the background of the scene - the most numerous pixels. But why are there 2 peaks here? That will become apparent after conversion to colour.
Because GRIP uses a logarithmic frequency axis it is easy to see that there are some single bright entries looking like hot pixels. I have written an algorithm to test this and it is clear that these single pixels are grouped together in (x, y) in the image and they are not the same in different image sessions, so they are not hot pixels. It seems that any defective pixels have been taken care of before the FITS files are saved.
The header in the FITS files includes this line:
BAYERPAT= 'GRBG ' / Bayer pattern
I have verified in my program that this means the RGB filter pattern in the top left corner of the image starts as
GRGRGRGR
BGBGBGBG
GRGRGRGR
BGBGBGBG
Having applied that pattern to make a 3-channel (RGB) version of the image, by averaging nearest neighbours (2 or 4) to fill the missing values, GRIP's histogram looks like this:
Notice that the blue modal frequency is significantly brighter than the red and green modes. I think this is because the M53 image was shot in the presence of an almost Full Moon. The Moon does make the sky blue just like the Sun does but it is so much fainter that our eyes do not perceive that. In GRIP I have an operation called "Neutralise background" which shifts 2 channels down so that their modal values match that of the darkest one. The JPEG files saved by my S30 do not show a brighter blue peak so I guess the device must be applying a similar technique.
Here is a profile across the brightest star in the RGB version of this first frame:
The red channel just reaches the largest possible value in a 16-bit image (65535). Is this by design or just a coincidence? I don't know yet. The second brightest star is almost as bright but in the blue channel only. This profile also gives some indication of the amount of noise present in the image.
A real measure of noise can be obtained in GRIP by profiling a line or histogramming an area that does not contain any stars:
Here the standard deviation measurements can be seen. Unsurprisingly the value is smaller for green. There are twice as many green pixels as red or blue in the original image.
Next question: have the images already been aligned before saving as FITS? It was easy to demonstrate that that is NOT the case, by adding every 14th file from across the M64 sequence:
This also shows that the track is not a smooth curve at all. The device deliberately dances around slightly to smooth out pixel variations. I looked at several files to see whether the (x, y) offsets are recorded in the FITS headers but they are not.
To be continued...