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 utilize 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 greenish and blue filters laid over the sensor's pixels.  For each group of iv pixels, ii are greenish, one red and one bluish.  The raw data read out from the camera'due south sensor volition exist gray scale with usually 8 $.25 per pixel but it tin be more.  To provide a colour prototype the raw information must exist 'de-Bayered'.  The simplest form of de-Bayering is called 'nearest neighbour' where, for each pixel, the nearest pixel for the other ii colours is used to provide the colour data so, for example, for a pixel underlying a dark-green filter, the data for the red and bluish will be obtained from the nearest pixels with these colour filters lying higher up them.  This is somewhat rough and can produce artefacts so, though fast to execute, information technology is non the best way to de-Bayer the raw data whether washed by the capturing software or subsequently in the stacking procedure.

To become the highest image quality, the stored data should be uncompressed so an uncompressed color file will require three, 8-fleck, words per pixel rather than one if a raw file is saved.  Saving a raw file volition thus require less processing ability and retentiveness bandwidth and information technology may exist that a college frame rate could be achieved.  The raw format 'codec' employed by many cameras providing 8-fleck information is called Y800 but there are others.

It is rather a pity that Registax, whose use I accept described in both books, applies the nearest neighbour algorithm to de-Bayer raw files rather than more sophisticated de-Bayering algorithms that could exist used such as bi-linear interpolation or, even amend, the HQ Linear algorithm.  Then, 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 exist then aligned and stacked in Registax.

Two free programs will de-Bayer a raw file.  Within the 'FireCapture' bundle is a stand alone programme called 'deBayer.exe' which volition de-Bayer a raw file using more than sophisticated algorithms such as HQ Linear rather than nearest neighbour.  A second programme 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 take establish that the 'HQ Linear' algorithm gives very good results.  Perhaps surprisingly, I plant that the de-Bayer.exe file gave a sharper stop upshot than that produced by PIPP.

Some tests of these thoughts

In the chapter on planetary imaging in 'The Fine art of Astrophotography' I wrote the following:

"I believe that it is best for the tracking to be 'not quite perfect' to let the planetary prototype to move very slowly across the sensor equally a video sequence of ane to two thousand frames is taken.  This improve samples the colour when a colour webcam is used (as individual pixels are only sensitive to one colour) and likewise helps remove the effect of any dust on the sensor.  [When, inadvertently, the tracking of my mountain was effectively perfect and the image stayed stationary on the webcam sensor, the blueprint of the RGB Bayer matrix was faintly visible in the resulting image.]"

I now believe this to be good communication and have washed 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 groundwork was non called specifically, it really helped to highlight the bug 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 six using it to de-Bayer the frames.  The event, seen below left at 200%, shows artefacts in both the wall and smooth region of the image − merely as I had seen in a planetary image processed in this way when the tracking was 'also skillful'.

My advice, above, was to allow the planet to slowly motion across the sensor equally I suspected that this would give a better image. To exam 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 non perfect.

The Registax image produced (middle left) when it de-Bayered the raw file nevertheless showed artifacts but these were less obvious. Note also that in that location was some detail in the diffuse groundwork so stacking a not 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 design had disappeared as seen below in the centre right prototype. 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 elementary 'nearest neighbour' algorithm used past 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 correct) with no artefacts than when the raw file was de-Bayered in PIPP and which again showed a petty detail in the background.

A slight puzzle.  When, using the raw file taken when the webcam was being slewed and the raw information was processed directly in Registax, the limit screen showed the move of the paradigm across the sensor, as it should have.  When I aligned both the deBayer.exe or PIPP color .avi files no motion was seen implying that both programs had aligned the frames equally they were being converted.  This is definately the case as I repeated the experiments with far longer video sequences and plant the aforementioned thing.

Every bit shown in this final comparing when Registax de-Bayed the raw file (left) and when it stacked the colour file produce past de-Bayer.exe using the HQLinear algorithm (correct), the stacked colour file gave a greater depth of color. One can also encounter that the latter has centred the image.  Incidentally, the 'burnt out' area lower right was snowfall.  Neither epitome has been post processed.

My communication

Practice permit the planets prototype to slowly move across the sensor – this, I am certain 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.  [Past taking a number (eight) of images when the sensor has been shifted past one-half a pixel in different directions, some Olympus cameras can produce ~40 Mpixel images from a xvi Mpixel sensor − so there could be some truth in this.]

Practise salve uncompressed raw files.

Never process raw files directly in Registax.

Pre-process these in PIPPS or deBayer.exe (preferably the latter) to requite a colour .avi file and and so process these in Registax or 'AutoStakkert! 2'.

Render to Astronomy Digest home folio