British Astronomical Association
Supporting amateur astronomers since 1890

Secondary menu

Main menu

Home Forums Imaging
Terms of use

Deep Sky Stacker V4.2.0

3 posts / 0 new
Last post
Clive Nanson's picture
Offline
Last seen: 1 week 2 days ago
Joined: 09/03/2014 - 09:42
Deep Sky Stacker V4.2.0

I updated to DSS version 4.2.0 (from 4.1.1) today and soon wished I hadn't!  With the new version, the RAW files have a slightly different size to the old version (2 pixels smaller) which meant that I had to re-create my existing masters because they no longer matched the size of the RAW files.  Then, after stacking some existing images (which, using the older version resulted in a reasonably white balanced image) had either a huge green or red colour cast.  Fortunately I've been able to revert back to the old version, but if anyone knows where I'm going wrong I would be happy to know. 

Offline
Last seen: 3 weeks 2 days ago
Joined: 05/03/2014 - 00:00
Deep Sky Stacker V4.2.0 Changes to RAW decoding

Hello Clive, I noticed no-one has answered yet, but it is holiday season!

From the DSS 4.2.x release the RAW decoding engine was changed from DCRaw to LibRaw, you can find out the reasons for the change by a quick Google search but in a nutshell DCRaw was the sole work of a software developer, Dave Coffin, who after many years of unpaid and unsupported work maintaining and updating DCRaw for new camera releases decided to throw in the towel, concentrate on his family life and paid employment and announced that DCRaw was at an end.

A competing RAW decoding engine, LibRaw, an open source project, was left to take over the work of decoding RAW DSLR files in a wide range of free and paid-for photography and astro-photography post processing applications.

Neither DCRaw or LibRaw produce definitive decoded images since the DSLR manufacturers, with the exception of Canon, go to great lengths to hide the algorithms used to decode RAW files, some even employ encryption routines to obfuscate the code and protect their intellectual property rights while the developers of DCRaw and LibRaw have to reverse engineer and experiment with the RAW's to come up with a suitable conversion.

This explains why your RAW images in DSS 4.2.0 are now being reported as a different size to those processed in DSS 3.x.x since there is not a published 'standard' size that they should be. Pretty much all CMOS DSLR sensors have unused rows and columns of pixels at the ends of the arrays and it is up to the RAW engine to decide what the 'real' size of the image should be.

If your camera is more than a couple of years old, is supported by DSS 3.x.x using the DCRaw engine and runs without problem on your OS then there is no reason to change to the latest 4.x.x version. It might be that in the future you will have no choice but to migrate to 4.x.x if an OS update renders 3.x.x unstable or unusable or you employ a new camera that was never supported by DCRaw. In that case you will have to make new calibration frames and you will not be able to easily add old 3.x.x data to new data from 4.x.x.

If you want to use DSS 4.2.0 then at present, 'Use Auto White Balance' does not function correctly in the LIbRaw/DSS 4.x.x release and the recommendation is to select 'Use Camera White Balance' or 'Use Daylight White Balance' then adjust the final colour balance in post processing. If your camera supports the option in its settings then 'Auto White Balance' should always be disabled for astrophotography if you wish to avoid calibration errors with flats, darks and bias frames but remember to re-enable 'Auto White Balance' in-camera for conventional photography.

You might like to open a topic on the DSS and LibRaw Wiki groups regarding the change of reported sensor size between 3.x.x and 4.x.x as this might be something that can be fixed for the next LibRaw engine release cycle, they will need to know the exact model of your camera, it's firmware version, a sample RAW file from your camera and an exact description of the problem. It's equally possible that the old DSS 3.x.x and DCRaw engine was misreporting your sensor size and that DSS 4.x.x and LibRaw is now outputting a 'correct' size image after decoding the RAW file:

https://groups.io/g/DeepSkyStacker

https://www.libraw.org/forum

You can stay up-to-date with DSS releases and known bugs on this page:

https://github.com/deepskystacker/DSS/releases.

HTH

William.

Clive Nanson's picture
Offline
Last seen: 1 week 2 days ago
Joined: 09/03/2014 - 09:42
DSS V4.2.0

Hi William, thanks for your comprehensive and informative reply and, if you’ve seen my members’ page, you’ll know that I’m new to this digital imaging so all the help I can get is more than welcome.

The change in the size of the decoded raw files was an inconvenience only because I was re-processing some existing images using previously compiled associated dark, flat and bias frames.  My camera is a Canon EOS 200D (which I believe was first released in mid-2017) and, looking at the latest source code of DCRAW, would appear to be supported by version 4.1.1 of DSS that I have been using (and have now reverted back to using in favour of version 4.2.0 that now uses LIBRAW).

I agree that the size of the processed RAW files can vary.  If I import my .CR2 files directly into IRIS they come out as 6288 x 4056 pixels so they have large black borders.  However, if I first convert them to .DNG files using Adobe DNG converter and then import them into IRIS, then they are 6024 x 4020 pixels which is the same size that DSS V4.1.1 converted them to (DSS V4.2.0 converted them to 6022 x 4020 pixels, an insignificant difference I know, but sufficient to generate an error message!).

However, your comments about auto white balance are of interest to me.  Having checked my camera settings, all images, darks, flats and bias frames that I’ve created to date have been with the camera set to ’Auto White Balance’.  I’ve been happy with the results so far (again see my members’ page for my first few images) but perhaps I’ve been lucky.  I have the ‘Auto White Balance’ option checked in DSS V4.1.1 and the resulting images have only needed a small tweak in post processing to achieve an acceptable white balance (no green stars!).  But, as you say, this option is no longer available in V4.2.0 and my existing images needed major white balance correction (effectively by using a best guess approach).  Having always believed in ‘if it’s not broke don’t fix it’, then I’m cautious to make changes - but perhaps that’s where I’m going wrong!