[This is just one of many articles in the author’s Astronomy Digest.]
An update to the chapters on planetary imaging in ‘An Amateurs Guide to Observing and Imaging the Heavens and ‘The Art of Astrophotography’ relating to the use of colour video cameras (webcams).
As I am sure that you are aware, a colour video camera employs the use of a ‘Bayer Matrix’ of red green and blue filters laid over the sensor’s pixels. For each group of four pixels, two are green, one red and one blue. The raw data read out from the camera’s sensor will be grey scale with usually 8 bits per pixel but it can be more. To provide a colour image the raw data must be ‘de-Bayered’. The simplest form of de-Bayering is called ‘nearest neighbour’ where, for each pixel, the nearest pixel for the other two colours is used to provide the colour data so, for example, for a pixel underlying a green filter, the data for the red and blue will be obtained from the nearest pixels with these colour filters lying above them. This is somewhat crude and can produce artefacts so, though fast to execute, it is not the best way to de-Bayer the raw data whether done by the capturing software or later in the stacking process.
To get the highest image quality, the stored data should be uncompressed so an uncompressed colour file will require three, 8-bit, words per pixel rather than one if a raw file is saved. Saving a raw file will thus require less processing power and memory bandwidth and it may be that a higher frame rate could be achieved. The raw format ‘codec’ employed by many cameras providing 8-bit data is called Y800 but there are others.
It is rather a pity that Registax, whose use I have described in both books, applies the nearest neighbour algorithm to de-Bayer raw files rather than more sophisticated de-Bayering algorithms that could be used such as bi-linear interpolation or, even better, the HQ Linear algorithm. So, if Registax is to be used for aligning and stacking raw video files, better results will be obtained if the raw .avi file produced by the video capture program is first converted into a full colour .avi file to be then aligned and stacked in Registax.
Two free programs will de-Bayer a raw file. Within the ‘FireCapture’ package is a stand alone program called ‘deBayer.exe’ which will de-Bayer a raw file using more sophisticated algorithms such as HQ Linear rather than nearest neighbour. A second program is called ‘PIPP’ (Planetary Imaging Pre Processor) which can also employ the HQ Linear algorithm to de-Bayer a raw .avi file. Using both programs, I have found that the ‘HQ Linear’ algorithm gives very good results. Perhaps surprisingly, I found that the de-Bayer.exe file gave a sharper end result than that produced by PIPP.
Some tests of these thoughts
In the chapter on planetary imaging in ‘The Art of Astrophotography’ I wrote the following:
“I believe that it is best for the tracking to be ‘not quite perfect’ to allow the planetary image to move very slowly across the sensor as a video sequence of one to two thousand frames is taken. This better samples the colour when a colour webcam is used (as individual pixels are only sensitive to one colour) and also helps remove the effect of any dust on the sensor. [When, inadvertently, the tracking of my mount was effectively perfect and the image stayed stationary on the webcam sensor, the pattern of the RGB Bayer matrix was faintly visible in the resulting image.]”
I now believe this to be good advice and have done some tests using Registax to align and stack a raw file largely of a brick wall but also of some smooth, out of focus, background. Though this background was not chosen specifically, it really helped to highlight the problems if Registax is used to de-Bayer the raw .avi file.
Using a tripod mount and camera lens, I used IC Capture to record a raw file with the webcam and lens stationary so the image was fixed over the sensor. I first processed the resulting raw file directly in Registax 6 using it to de-Bayer the frames. The result, seen below left at 200%, shows artefacts in both the wall and smooth region of the image − just as I had seen in a planetary image processed in this way when the tracking was ‘too good’.
My advice, above, was to allow the planet to slowly move across the sensor as I suspected that this would give a better image. To test this hypothesis, I took a further video sequence but, this time, slowly moved the camera at half sidereal rate (using my nano-Tracker) to simulate tracking that was not perfect.
The Registax image produced (centre left) when it de-Bayered the raw file still showed artifacts but these were less obvious. Note too that there was some detail in the diffuse background so stacking a non stationary .avi file seems to have improved things somewhat.
I then de-Bayered the raw file, taken with the camera stationary, using the PIPPS program with the HQ Linear algorithm to produce a colour .avi file. When this file was processed in Registax the pattern had disappeared as seen below in the centre right image. This image was considerably softer than that produced when Registax de-Bayered the raw file but all artefacts had gone. This, I think, proved that the simple ‘nearest neighbour’ algorithm used by Registax created the artefacts.
My final test on these video files was to de-Bayer the raw file using the deBayer.exe and HQLinear algorithm with the resulting colour .avi aligned and stacked in Registax. This produced a considerably sharper image (far right) with no artefacts than when the raw file was de-Bayered in PIPP and which again showed a little detail in the background.
A slight puzzle. When, using the raw file taken when the webcam was being slewed and the raw data was processed directly in Registax, the limit screen showed the movement of the image across the sensor, as it should have. When I aligned both the deBayer.exe or PIPP colour .avi files no movement was seen implying that both programs had aligned the frames as they were being converted. This is definately the case as I repeated the experiments with far longer video sequences and found the same thing.
As shown in this final comparison when Registax de-Bayed the raw file (left) and when it stacked the colour file produce by de-Bayer.exe using the HQLinear algorithm (right), the stacked colour file gave a greater depth of colour. One can also see that the latter has centred the image. Incidentally, the ‘burnt out’ area lower right was snow. Neither image has been post processed.
My advice
Do allow the planets image to slowly move across the sensor – this, I am sure samples the colour better and some believe that this actually increases the effective resolution and brings it closer to that achieved with a monochrome sensor and filter set. [By taking a number (8) of images when the sensor has been shifted by half a pixel in different directions, some Olympus cameras can produce ~40 Mpixel images from a 16 Mpixel sensor − so there could be some truth in this.]
Do save uncompressed raw files.
Never process raw files directly in Registax.
Pre-process these in PIPPS or deBayer.exe (preferably the latter) to give a colour .avi file and then process these in Registax or ‘AutoStakkert! 2’.
Return to Astronomy Digest home page