logo
background
 Home and Links
 Your PC and Security
 Server NAS
 Wargames
 Astronomy
 PhotoStory
 DVD making
 Raspberry Pi
 PIC projects
 Other projects
 Next >>

The what and why of "RAW' images

What's RAW ?

How does the Camera sensor generate the output image ?

The sensor contains millions of light sensitive detector pixels. Each individual detector as a filter placed in front of it that limits what 'colour' it can see (the filter is typically combined with a 'micro-lens' that focuses light on the detector).

Image In most camera's, detector pixels are organised into groups of 4 in a simple square pattern known as a 'Bayer Matrix', 2 G's, 1 R & 1 B (as seen left).

The Bayer Matrix sets are processed within the camera to generate the RGB output. The actual processing is more complex than you might think. An 8 mega-pixel Camera may have 8 million detector pixels but this is only 4 million Green plus 2 million each of Red & Blue. From this, the camera will output an image with 8 million RGB pixels

So at each of the pixel positions, 2 of the colours for that position must always be determined (by interpolation) from the surrounding pixels. Further, whilst the raw single colour detector is typically 12 or 14 bit resolution, the RGB output is only 8 bits per colour.

Interpolation will smooth (or 'smear') the detected values to generate the output & then throw away most of the resolution, after which the camera 'squeezes' the data into JPEG format (which results in even more of the original data being thrown away) before outputting the result

Fortunately, almost all DSLR cameras have the option of saving the full set of original unprocessed 12 (or 14) bit pixel sensor data in the manufacturers own 'raw data' format.

What is RAW data ?

The RAW data is exactly that. It's the full resolution values from each individual sensor pixel before any sort of processing. It thus also contains that pixels individual 'noise' and the combination of the individual filter efficiency and individual detector sensitivity. Further, since in any semi-conductor the size of the average DSLR sensor array there will be a few defects, plainly some of the detector values will be drastically 'incorrect'

However, once you get access to the raw data you can do your own processing - and that means it is also possible to do clever things such as generating a high precision 8 mega-pixel 'black & white' image

Unfortunately, camera manufacturers RAW formats are neither 'standard' nor stable - Canon has changed formats 3 times (they originally offered TIFF, then 'CRW' and now 'CR2'). Further, manufacturers tend not to publish full details of their 'own' formats and although most are actually based on TIFF, some manufacturers use non-standard compression or even encryption !

Thus the first step in any real processing is to convert your camera 'RAW' into something more 'standard' that can then be processed by specialist astro-photography software.

I look at the various possible standards below

What about Adobe DNG ?

DNG ("Digital Negative") is an attempt at an 'industry standard' RAW formats. Unfortunately, this is 'owned' by Adobe = the very well known American company that rips off the UK consumer with £1=$1 pricing (and then some extra on top).

Whilst Adobe makes available a free 'RAW to DNG' converter that supports most camera manufacturers proprietary RAW formats, they are not much better at maintaining compatibility with previous versions than the manufacturers themselves are. Further, their entire (and only) reason for offering such conversion is to entice you into laying out £300+ for their Photoshop software

Because the format is proprietary, it can never be established exactly what processing they may be doing during the 'conversion' to DNG and what data has been lost (converting .CR2 to DNG and back again never gives the same file size, never mind the same file contents)

It is known, for example, that Adobe imposes it's own proprietary 'badpixel' replacement algorithm during import to DNG. It is understood that Adobe also 'throws away' boundary (or 'edge') pixels that the Canon CR2 format declares as 'out of the active picture area'.

These undocumented 'features' can not be disabled and it's anyone's guess what other processing is imposed on the RAW data before Adobe allows you to save it as DNG

When it comes to DNG, well, since I believe that, as a rule, you should avoid all non-open-source software .. and especially that offered by American companies with their not-too-carefully hidden commercial agendas ..

In sort, I would not touch DNG with a barge-pole (especially as I expect Adobe takes the same attitude to DNG as they do to PDF - i.e. attempt to jail anyone who explains how to bypass Adobe's restrictions on use or sue anyone who has the 'cheek' to write software that 'competes' with Adobe's own)

Adobe also has no little interest in ensuring 'non-compatibility' with 3rd party plug-ins, especially when these could be seen as a 'threat' to their own (commercial) agenda. This might mean, for example, taking action to prevent PS use with "non-Adobe" (i.e. non-proprietary) image formats. Thus, for example, it should comes as no surprise to discover that the latest version of Photoshop (CS5, May 26, 2010) was modified to prevent it working with FITS Liberator 2.3. As of July 2010, no solution has been posted.

How about 16 bit per channel TIFF ?

This is an older but still quite 'popular' intermediate format. It's also the 'natural' choice, since many of the Camera manufacturer's own proprietary formats (such as Canon CR2) are based of TIFF (so minimal conversion is needed).

The professional astronomers own format, FITS ?

Whilst used extensively by NASA (see NASA FITS support page) and ESA, there seems to be very limited support from the Open Source / Astronomy community for converting camera RAW into FITS.

Convert RAW data into standard (TIFF or FITS) format ?

Various packages claim to import Canon CR2 RAW and 'save as' TIFF. Some of these are examined below.

A1. dcraw.c

This Open Source code supports multiple different camera RAW file formats and (from a source code examination of the 'options') this code is able to support unmodified output to a 16 bit per channel TIFF.

During 'import' if a 'badpixels' file is found, it will also 'map out' (replace) the indicated pixels and replace them with the simple average of the 4 corresponding sub-pixels from the surrounding Bayer Matrix 'sets'.

Because of it's wide support for many different camera manufacturers RAW formats, dcraw has been incorporated into many other packages, many of which are re-complied & re-released when a new version of dcraw is released.

Unfortunately, since most of these other packages are aimed at specific tasks (with RAW input of secondary importance), often dcraw is used only for import (and it's output capability is omitted).

A2. UFraw

One package that uses dcraw and promises (in it's own 'Help' file) FITS support is UFraw. This utility uses dcraw to import the RAW files (and thus supports bad-pixel mapping).

Because of the bad pixel replacement feature, I spent some time trying to get UFraw to work with FITS.

Unfortunately it suffers from the same problem that almost all packages that can read RAW format files suffers from - it insists on processing the data into garbage (RGB) before allowing the user to save it.

Further, it turns out that the promised FITS file output support has never ACTUALLY been assembled into any of the pre-complied Windows versions - to enable FITS it is necessary to re-compile with an additional library, "libcfitsio". Since the developer has no interest in the Windows environment at all, there seems little chance of this utility ever being of any real use.

Finally, UFraw does support TIFF output, but once again, what I got was processed 8 bit per colour RGB TIF, despite setting the 16 bits per colour 'flag' (I assume that, even if it had 'worked', all I would end up with is 16bit RGB, not the 16bit Bayer Matrix GR,GB).

UFraw is a typical example of a 'shareware / freeware' program - it was developed to achieve a specific function and then 'released'. The documentation reflects the capabilities of the component parts (such as dcraw) but plainly no actual testing has ever been done to confirm what works (if anything) beyond what was needed for the developers own use

A3. IRIS

This package appears to promise FITS support. Unfortunately the software developer is French and the English translations leave a lot to be desired :-)

On initial testing, this package looked quite promising, since it does actually generate files with the suffix "FIT" or "FTS" (plus some proprietary form of "PIC").

However the stated internal precision is only 15 bits, since, for some reason known only to the developer, 'negative' values need to be supported during internal calculations. So the internal precision is signed 16 bit integers, and the developer admits that the precision of incoming (16bit) FITS images is ACTUALLY HALVED on import. Needless to say, I have no time for such cavalier treatment of data and would never trust any software from an author that plainly can't be bothered to think about retaining maximum precision during processing (never heard of 32bit floating point perhaps ?). IRIS does support Canon's .CR2 file format, however it seems to be incapable of importing the actual data without applying some sort of 'conversion' into who-knows-what.

What's the problem ?

Most imaging package software developers have no real interest in preserving maximum data precision. Almost all their efforts go into reducing the data (during import) to 8 bit RGB in order to display "pretty pictures" to the user as quickly as possible

When it comes to commercial software, the concept of allowing any user control of the import process or of saving intermediate full resolution 'raw' data is generally alien to their thought processes. US developers in particular adopt a 'we know best' attitude with a belief that, the more they can "hide" what they are doing to your data, the greater the 'commercial advantage' they will achieve.

Indeed, browsing the web for raw file conversion, it will be quickly discovered that even 'open source' developers are much more interested in 'pretty pictures' than in data preservation

Unless you want to go the DNG route, you have little choice but to search for astro-imaging software that will directly import your camera RAW format. Fortunately, Canon's market share (and the astro-imagers use of the 300/350D) means that Canon CR2 is one of the most commonly supported formats.


For an in depth look at defective pixels (and what can be done about them) and whats needed to extract a deep sky image from the raw data, click "Next >>" (in the Navigation bar to the left).

Next page :- Defective pixels - (what are they)

[top]