Page top

Home page

Contents

Index

API (for
programmers)

Page bottom

Next page

ZWO SeeStar S30

 

 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

 Some night sky results

M16 Eagle Nebula

Asteroid 2 Pallas

The Veil Nebula

M27 Dumbbell Nebula

 Field of view

2.13 x 1.20 degrees

(From focal length 150mm and 1920 x 1080 square pixels, each 2.9μm across.)

 First deep sky attempts

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 and stack these files and a new version is available (see below).

FITS standard

Bayer pattern

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.

Previously I showed here a photo of a white card which had obvious vignetting. That was a mistake because it was taken through the small wide-angle lens of the S30. Repeating the test with the normal lens always produced a completely uniform (flat) result, so the S30 must always be applying a field flattener, even in the scenic mode.

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.

I have made GRIP output the dance of the brightest star in the M53 sequence, partly due to the alt/az tracking but also with deliberate offsets I am sure. On the detector chip in the S30 this trace is 161 pixels wide and 79 pixels high:

 Files saved for each exposure

If set to do so, Seestar saves 3 files for each exposure:

• .fit = 1080x1920px, 16 bits, size about 4Mb, monochrome FITS format needing de-Bayering
• .jpg = 1080x1920px, 8 bits, size about 1Mb, RGB medium quality
• _thn.jpg = thumbnail 148x264px - no use for processing

Example of the root file name, the same for all 3:

Light_M 27_10.0s_LP_20250804-224233
frame target   filter      local time
type     exposure     date

 New GRIP version

I now have a version of GRIP that can stack the "raw" files from SeeStar, both FITS and JPEG (but ignoring the thumbnails). It uses a rubber-sheet warping method, not just shift/scale/rotate. I am now investigating whether this (re-stacking outside the S30) provides benefits.

The new version 25.8.28 of GRIP is now available. Follow instructions here to get the new .jar file after installing the previous version (18.3.3).

This version has the option to first align the images and then find the median value of every pixel through the sequence. This is a good way to reduce noise: at source rather than after stacking. On the Batch/Astro menu either do a normal stack or, in two (lengthy) steps, a median stack:

 Why re-stack inside Seestar?

While in Stargazing mode, taking photos, the Seestar aligns successive images and adds them so that a JPEG version is seen developing on the controlling smart phone. At the end there are also stacked files in FITS and JPEG format available on the Seestar, named something like this:

Stacked_390_M16_10.0s_LP_20250826-232206.fit
Stacked_390_M16_10.0s_LP_20250826-232206.jpg

(for a stack of 390 10-second images of M16, the Eagle nebula).

If the Seestar has been set to save the individual images there will also be a subdirectory containing those individual files (FITS plus JPEG versions - 390 of each in the M16 example just indicated). These individual files can be restacked using the "Deep Sky Stack" option in the application program. My S30 took about 20 minutes to restack those 390 images. Why bother?

I thought I would compare the two stacks by using GRIP to subtract one from the other. GRIP has a "Subtract to grey" operation which enables both positive and negative differences to be seen. Here is a portion of the result:

That immediately shows that the positions and orientations of the two versions are different. Trying to align both I found that the difference is not simply scale/translate/rotate but a more subtle warping. My guess is that the re-stack aims to correct for lens distortion. It could do more than that though, as I will attempt to explain.

Here is a comparison between a portion of my result, stacked the two ways, plus a third version made by my own GRIP:

All three of those have been put through a slight curve adjustment to see more of the background. I was hoping to see that the S30 re-stack would have reduced the background noise but no such effect is apparent. The GRIP version is different and I will explain how it was made.

The Batch/Astro menu in GRIP for working with sequences of images like this has two relevant options:

• Warp/shift onto common basis
• Create median pixels image

(And I now have a SeeStar-specific version of the first of those.)

The first of these analyses the patterns of bright stars in each image so that they can all be aligned and resaved as new files containing the realigned versions of the original images. The second option then re-reads the new files to make lists of the all the values for each pixel. It then makes a new image from the median values of those lists. In that way noisy or extreme values are eliminated so the end result is less noisy. I think this is much better than trying to correct noise after stacking. However the process is a long one, the time depending on how much memory is available. Generally GRIP divides the images up into strips for such processing, reloading all the files to get each strip.

 Bright stars

I noted earlier that the brightest star in my first deep sky image only just reached maximum image level. I wondered whether the S30 could be adjusting its gain (like camera ISO) depending on the brightest star in the field. I tested this by imaging Muphrid (η Boo) and Arcturus (α Boo). The gain value recorded in the FITS header remained at 200 for all cases, so there is no adjustment. My image of Arcturus is clearly saturated (and so was Muphrid):