Could Jpegs be better than raw? A test imaging the Hyades and Pleiades Clusters.

The Pleiades and Hyades Clusters processed from Jpeg frames

The conventional wisdom is that stacking and aligning raw files – which may have a 12 or even 14-bit depth must be better than using  Jpegs which have only an 8-bit depth and may well show artefacts. Over the years I have been surprised how well images have turned out when only Jpegs have been taken so decided to carry out a test processing both sets, raw and Jpeg, of 50, 25 second frames,  taken with a superb 45mm Zeiss Contax G lens (set to f/4) mounted using an adapter on to my Sony A5000 mirrorless camera. (See article in the digest about this camera.)  An ISO of 350 was used.  The frames were taken from an urban location (and sadly over the town centre) but with a reasonably transparent sky and an overhead limiting magnitude of 5.5.  The frames thus included a significant amount of light pollution.  As seen below, I found that the result from using the Jpeg frames appeared  more attractive than that derived from the raw frames.  In particular, the Jpeg result showed the nebulosity surrounding the Pleiades Cluster far better.  Why could this be?

There is absolutely no doubt that a single Jpeg bears no comparison to a single raw image as the crops of the region containing Aldeberan and part of the Hyades Cluster show. 

But what if a large number, in this cases 50, Jpegs are aligned and averaged?   It turns out that the advantage of raw over Jpeg is greatly reduced.

How Jpegs can rival raw files.

The key point in the description above is that 50 frames were stacked.  As I will try to explain, this greatly increases the effective bit depth of the result providing noise is present in the image.  So this advantage of using raw files may not be as significant.

The signal relating to each pixel is converted into a digital number in an analogue-to-digital converter.  Consider this scenario.  Suppose the actual value of the output of a pixel, using a 12-bit converter to  digitise the output  from a pixel is 221.3.  This will be stored in the raw file.  If this value were reduced to 8-bits in the Jpeg conversion it could only give integer results of 221 or 222.  (The 8-bit range is 0-256.)  If there was no noise affecting the output of the pixel the A-D would always give the nearest value which is 221.  Obviously not as good.  However now let’s add some noise into the signal  that is output from the pixel – there will be!  The values successively read out from the A-D will now vary, certainly giving values of 221 and 222 and quite likely some (but fewer) values of 220 and 223.  Because the real value of the pixel output is 221.3, there will be more readings giving 221 and 220 and fewer of 222 and 223.  If a reasonable number of these 8-bit values are averaged – as will happen when a set of Jpeg frames are aligned and stacked using 16 or even 32 bit-depth accumulators, the average will lie closer to 221 than 222 and will likely to be very close to 221.3.  So averaging a number of 8 it values where noise is present will increase the effective bit depth of the result so eliminating that advantage of raw files.  I promise that this is true. 

I also suspect that when converting the sensor data into a Jpeg, some ‘stretching’ of the image is carried out to lift up the fainter parts of the image.  This sometimes  appears to be the case when I have compared single raw and Jpeg frames − not just relating to astrophotography − and will depend on the camera being used.  Averaging a number of frames would also probably reduce or remove the Jpeg the artefacts that are present  and seen in the image above.  So it is not impossible that stacking a reasonable number of Jpeg frames (say 15 or more) could actually give a better result − as I believe in this image.

Processing the raw and Jpeg images

Sequator (see article in the Digest) was used – it is very fast.  The frames were loaded into Sequator and aligned and stacked without using any of the possible adjustments.  The 16-bit Tiff result was then loaded and processed in Adobe Photoshop.  However the free program GIMP could also be used and the digest includes an article about using GIMP to remove light pollution which is somewhat more difficult than in Photoshop.

The stacked image below showed, as expected, significant light pollution.

Image stacked from 50 Jpeg frames showing the light pollution.

Removing the Light pollution

The image was duplicated and the ‘Dust and Scratches’ filter applied with a radius of 30 pixels. The filter ‘thinks’ the stars are dust and removes them but the Pleaides cluster and Aldebaran are still visible. 

These were cloned out from an adjacent part of the image (hoping that the light pollution will be similar)  and the Gaussian Blur  filter applied also with a radius of 40 pixels to give a very smooth image of the light pollution which varies across the frame.

The two layers were then flattened using the ‘Difference’ blending mode with an opacity (default) of 100%.  The light pollution is removed from the original frame.

Stretching the image

Either the levels or curves tools can be used.  In levels, move the central slider leftwards to 1.2.  This brightens up the fainter parts of the image more than the brighter.  After a few applications to suit your preference, a further application is used moving  the left slider to the right to increase the black point and so remove the noise from the image. 

In curves, lift up the left hand part of the curve to have the same effect.

Hot pixels and their removal

I had deliberately slightly misaligned the axis of the nanotracker on the North Celestial Pole.  This was done to eliminate what Tony Hallas calls ‘Color Mottling’ (He is American.) −  variations in the sensitivity of different colour pixels on scale sizes of ~20 pixels.  This can give the background noise, which should be a uniform very dark gray, a random coloured pattern.  Because of the misalignment,  over the course of the imaging exercise the stars − but not the hot pixels − will move across the sensor.  They will thus give a linear track when the frames are aligned and stacked as seen in the image below.   Had I used the ‘In Camera Long Exposure Noise reduction’ when the camera follows each light frame with a dark frame, the hot pixels would have been eliminated.  But this both adds some noise to each frame but also halves the time imaging the sky!   So my Jpeg result showed quite a number of red and blue streaks across the image.  I thus had to spend a few minutes ‘spotting’ them out with a black brush.   What I do not understand too well is that the result of aligning and stacking the raw frames as described below did not show them.   This, I suspect, is because the Jpeg conversion stretched the image and so increased their brightness relative to that in the raw frames.  As the misalignment spreads out their light, it could be that they came below the noise level in the raw result.

The final Jpeg result

As shown below, the six bladed iris of the Zeiss lens gives the brighter stars a 6 pointed diffraction pattern.  That of Aldebaran has been ‘softened’ using a local application of the Gaussian Blur filter.  There is a small open cluster, NGC  1467 over to the left of Aldebaran.   I was really pleased how much nebulosity surrounding the Pleiades cluster had been capture in the Jpeg version.

Processing the raw frames

The Sony camera produces .arw files which can be accepted by Sequator.  They can also be converted into .Tiff files in both Adobe Lightroom or Sony’s own raw converter.

I first loaded the set of raw files into Sequator and removed the light pollution and then stretched the result exactly as for the Jpeg result.   I was very disappointed with the result.  The crops below show the region of the Pleaides Cluster compared to that of the Jpeg version.  The nebulosity is not nearly as well delineated however more stars were visible within the image.

In another article in the digest, I have advocated (as have others) first converting the raw frames into Tiff files and then stacking these.  Theoretically, the result should be no different, but it is often better.  So I did this and aligned and stacked them in Sequator with the result shown below in comparison with the Jpeg result.  Better, but still not as good.

I have also aligned and stacked the frames in Deep Sky Stacker and there was no obvious difference.

Conclusion

The results did not totally surprise me as I have had pleasing results when I have only captured Jpeg frames, but the difference was far more than I had expected.  I can see, as explained above, why when averaging many Jpeg frames their obvious loss of quality can be partially overcome.  But that should not make the result better than stacking raw frames.  I can only surmise that the suspected stretching of the image when the camera produced the Jpeg version has helped.  In principle, one could do a slight stretch of each Tiff file before the stacking process and that may improve the result.  So I tried converting the raw files in Adobe Lightroom applying a tone curve to lift up the fainter parts of the image.  The overall result was better but the nebulosity was still not as well captured as with stacking the Jpeg files.  It must be possible to get a better result using the raw files – but I do not know how to do it.

The moral is this: build up the sensitivity of the image by taking many (at least 20) short exposures and  store both Jpegs and raw files for each frame.  Process both and you might find, as in this example, that you prefer the Jpeg result.