deepskystacker/dss

DeepSkyStacker

DeepSkyStacker

This is the github repository for all the DeepSkyStacker source code.

DeepSkyStacker is freeware created in 2006 by Luc Coiffier

It was open sourced in 2018 and is maintained by a small and dedicated team:

David C. Partidge, Tony Cook, Mat Draper, Simon C. Smith, Vitali Pelenjow,
Michal Schulz, Martin Toeltsch, Iustin Amihaesei

The code is open source under the terms of the BSD 3-Clause License (see LICENSE).

Copyright (c) 2006-2019, Luc Coiffier Copyright (c) 2018-2023, David C. Partridge, Tony Cook, Mat Draper, Simon C. Smith, Vitali Pelenjow, Michal Schulz, Martin Toeltsch, Iustin Amihaesei

Building DeepSkyStacker:

To work on the current development codebase which uses a VS solution file called DeepSkyStacker.VS2022.sln, you will need to install Visual Studio 2022 (17.7.2). For earlier code versions either VS2019 or VS2022 will work.

If you open DeepSkyStacker.VS2019.sln (or an earlier level) using VS2022, please do not accept VS2022's offer to upgrade the build environment the first time you open the DeepSkyStacker.VS2019.sln file.

In addition to Visual Studio, you will need to install Boost 1.80.0 Qt 6.4.0, Qt 6.5.3 and Qt VS Tools 2.10.1 (rev 2), and Visual Leak Detector.

Boost

Install Boost 1.80.0. Once you have done that, you need to create an environment variable called Boost_1_80_0 with the location of the Boost installation directory e.g.: C:\Boost_1_80_0

Qt 6.4.0, Qt 6.5.3, Qt VS Tools

Qt 6.4.0 is needed to build DeepSkyStacker 5.1.0 through 5.1.3. Qt 6.5.1 is needed for the current development build which includes support for WIndows Themes. In addition to you you will also need to install the Visual Studio Extension Qt VS Tools : (Extensions/Manage Extensions).

You will need to use Extensions/Qt VS Tools/Qt Versions to set up two named Qt Installations called:

6.4.0_msvc2019_64 and
6.5.1_msvc2019_64

pointing to the msvc2019_64 sub-directory of your Qt installations (for example C:\Qt\6.4.0\msvc2019_64).

Visual Leak Detector

You should install the version of VLD that is maintained by the Microsoft Azure development team as that appears to be the only one that is being kept up to date. You can download the 2.5.9 of this from Visual Leak Detector. You should install it to C:\Program Files (x86)\Visual Leak Detector as that is the location that the DeepSkyStacker projects expect to find it. In the Visual Leak Detector installation wizard, be sure to check "Add VLD directory to your environmental path".

dss's Issues

Using DSS icon in installer/uninstaller instead of installer default??

I noticed in the latest DSS beta, the default icon of NSIS installer is used instead of DSS. The same happens to the uninstaller icon in Control Panel.

Can you change the icon back to DSS's.

Version for Linux

Hello,

is it possible to compile and run it on a Linux machine?
I (and many more Linux users) would be glad about a tutorial.

Kind regards

DSS freezes upon generating a Star Mask and changing the extension to FITS

When generating a star mask from the "Create a star mask..." button on the left under "Processing" the file produced generates without a file extension.

Seems to be a .tiff like everything else produced. Adding .tiff manually seemed to work well enough to import to Photoshop.

Any chance for a OSX version?

Hi there

As a fellow developer, I know this is a big task.

But any plans on making an OSX version? Maybe by utilising QT for the UI?

Hourglass while post-processing change being processed

When DSS is making a change to brightness or saturation etc on a finished stack, it progresses in a spiral tile-by-tile fashion.
Sometimes when the changes are subtle it's hard to see the progress of the tiles, so I wait for 20 seconds and then hope it's finished updating the image.
Hows about a boring progress bar or hourglass to show the progress ?

Need to set software release in TIFF header in a smarter way.

Currently this is read from IDS_DEEPSKYSTACKER in TIFFUTil.c

		strSoftware.LoadString(IDS_DEEPSKYSTACKER);
		TIFFSetField(m_tiff, TIFFTAG_SOFTWARE, (LPCSTR)strSoftware);

problem is this didn't match the current release and the many .rc files setting it had different values.

I just updated many .rc files to change this to read "DeepSkyStacker 4.1.1" as a temporary fix.

We need to do this in a smarter way so we don't need to update MANY resource files at a release change.

Dave

Add a color workflow for monochrome ccds

Hi, could you add a color workflow for monochrome ccds?

I have an asi 1600 mm-cool monochrome ccd. DSS works with its monochrome files.

But in the end, I only can get L,R,G,B black and white pictures from DSS.
Unfortunately, I must use additional tools like fitswork or the expensive pixinsight in order to combine them to a color image.

Could you add a mode for monochrome cameras to DSS?

One should be able to group luminance, red, green and blue lights and flats and then DSS should automatically stack and combine them correctly to a color image.

Additionally, DSS may support false color imaging like the hubble pallette or other color schemes

Convert from DCRaw to libraw

Before or after 64 bit???

Stacking method not shown in recap file

The stacking method is not written in the recap file. It occurred when the average was selected but it was ok for kappa-sigma clipping and auto adaptative average.

Autosave012.html.txt

DSS doesn't handle Fuji RAF files

Just reported on StarGazersLounge:

"Just a heads-up that this new version doesn't open Fuji RAF files, as before. This isn't unexpected given that the Fujis don't use a conventional Bayer filter array, but I thought I'd try anyway. The program doesn't object to the files, it's just that they result in a totally black frame."

I replied that libraw may solve this and have asked for some files for testing.

David

Comet stacking ignoring comet position

I'm trying to stack images using the comet stacking function. I marked the comet in all frames, and tried both stacking methods, but DSS (4.1.1 / 64 bit) ignores that and aligns the Stars.

After that stacked the frames with DSS (3.3.2 / 32 bit) and the same settings and it worked:

Upgrade QHTML to current release?

If there's a newer release available!

Improve logging

Short term change location to use "User Documents" directory, not location of the exe file.

Longer term add class method tracing etc using tracing macro set. I have such a set, but needs work for Unicode support

Option so that autosafe.tif is saved as "uncompressed TIFF"

The Output of a stack process is saved as autosave.tif.
Unfortunatelly this is "compressed tiff" and it can not directly be loaded in "Astroart" for further postprocessing.

It would be nice if there is a Checkbox in "Setings" >> "Stacking Parameters" >> "Output", so that compression can be disabled or changed like in the "Save File As"-Dialog.
The Setting should be stored permanently in registry.

Thank You
Norbert

Proposed enhancements for .dssfilelist

From Ray Butler:

2 enhancements that I’d like to see to DSS. Both concern the .dssfilelist, which is key to the smooth operation of the program.

1a) When the .dssfilelist contains RAW calibration frames (dark/flat/bias etc.), the program should provide the option to check whether they have already been stacked to a “master” frame in the same folder as those frames, and use that instead. There is no point in repeatedly running the exact same operations again, when either re-running a stack with different options, or re-using calibration files which were already applied to another target/list.

1b) When saving the .dssfilelist after stacking, the program could also provide the option to replace the RAW calibration filenames in the list with the name of the corresponding “master” frame(s) that were produced from them. But 1a) is more important to have than 1b).

2. At present, the .dssfilelist is saved with full paths, from the disk root. This is a real nuisance if you use more than 1 computer, or host your DSS work on a portable disk, because every machine uses a different root name. For the most part, I use a 4TB USB3 disk, and process on either a home desktop PC, a laptop when on-the-go, and a Mac at the office (running Windows via VMware). Every machine mounts the USB3 disk under a different path/root. So a .dssfilelist created on one machine is invalid on every other machine; DSS can’t find any of the files, because the start of all the pathnames is different in the .dssfilelist to where the files are mounted now.
   The use of relative paths would fix this at a stroke. Every path would be stored relative to the saved location of the .dssfilelist. So instead of:
   G:\Astropics\2018_07_19\M8\M8.dssfilelist
   …containing:
   G:\Astropics\2018_07_19\M8\file1.raw
   G:\Astropics\2018_07_19\FLATS\file2.raw
   G:\Astropics\2018_07_15\BIAS\file3.raw
   …you’d have instead:
   M8.dssfilelist, at G:\Astropics\2018_07_19\M8\ - or at C:\2018_07_19\M8\ - or at \vmware-host\Shared Folders\Maxtor_4TB\Astropics\2018_07_19\M8\ - it doesn’t matter where!
   …containing:
   .\file1.raw
   ..\FLATS\file2.raw
   ....\2018_07_15\BIAS\file3.raw
   This list would work on every machine containing a copy of the data, or to which you connected a disk containing the data.

Turning whitebalancing off during RAW conversion

Other stacking solutions such as PI and APP have an option (usually set by default) to keep the RAW conversion process from applying any white balancing and camera-dependent matrix multiplication.

The need for this comes forth from the differing signal quality characteristics in the 3 channels. In the case of a Bayer matrix, for example, there are twice as many green samples as there are blue and red samples.

Applications that can take advantage of this fact (e.g. StarTools) for the purpose of maximising signal fidelity are unable to do so when DSS insists on color balancing the dataset (and - worse - applying camera-dependent color correction matrices). Meddling with the color channels creates complex, unpredictable blends of signal vs noise for each color channel.

As the creator of StarTools, this long-standing issue has been the major thing has kept me from recommending DSS as a preferred pre-processing solution companion.

A StarTools user has identified the code that is responsible for this forced whitebalancing;
(original post here)

In DSS-4.1.0-Release\DeepSkyStacker\RAWUtils.cpp, line 879, the function

BOOL CRawDecod::LoadRawFile(CMemoryBitmap * pBitmap, CDSSProgress * pProgress, BOOL bThumb)

assembles the dcraw command line to import the .CR2 files. It also sets some globals with a call to SetWhiteBalance() at line 996. Those globals aren't use in the dcraw call, though.

Here are the white balance options LoadRawFile sets for dcraw. The '-r 1 1 1 1' is not to be found in the function.
bValue = FALSE;
workspace.GetValue(REGENTRY_BASEKEY_RAWSETTINGS, _T("AutoWB"), bValue);
if (bValue)
{
// Automatic WB
argv[argc] = _T("-a");
argc++;
};

bValue = FALSE;
workspace.GetValue(REGENTRY_BASEKEY_RAWSETTINGS, _T("CameraWB"), bValue);
if (bValue)
{
// Camera WB (is possible)
argv[argc] = _T("-w");
argc++;
};

if (!m_bColorRAW)
{
// Document mode
argv[argc] = _T("-d");
argc++;
};

To be clear, the proposed -r 1 1 1 1 option sets a custom white balance of 1.0 for the RGGB samples.
From the dcraw help;

-r Set custom white balance

Please do let me know if anything is not clear. Clear skies!

Support for additional languages (Japanese)

I want to support Japanese. And I would like to contribute to Japanese language support.

Error reading RAW files from new Sony cameras

DSS has problems reading RAW files from new Sony cameras like A99ii. Images are striped and contain rather random looking pixels.
Here is a 100% view from DSS:

May provide full raw image (80MB) on demand.

Feature request - maintain image zoom and position when file changes

I like to manually review all of my light images prior to including them in the stack. I will zoom in on a portion of the image and verify the stars are to my liking. When I select a different image it resets the zoom. It would be helpful if there was an option to keep the zoom and view port of the image when I change to a new image if the image is the same dimensions. Are you open to adding a feature like that?

Problem with incorrect window display after minimise restore

To reproduce, load enough lights for scroll bars to be required in the file list.

Grab the resizing bar above the file list and move upward to reduce the image area.

Minimise DSS, and then restore. The image area comes back larger than before the minimise and the bottom of the file list with the group tabs is gone. The scroll bars may also be gone or incomplete.

Before minimise:

After restore:

Use default browser instead of IE

DSS 4.1.1 x64
Windows 10 v1803 x64

This is a feature request. Can DSS use user's default browser instead of IE when link is clicked in DSS??
But still Thank you very much for the great work!!!!

Truncated text in Computing Offsets message box

Text in Computing Offsets message box is truncated rather than wrapping to next line so you can't see which file it is currently processing:

Dave

Bug in file lists: Deep sky stacker can not have same dark or bias files in several groups

Hi there,
I have a dso object photographed with two different gain values (this corresponds to different iso settings) but the same exposures with a monochrome camera in LRGB.
This means I must use several groups, say Gain1 Luminance, Gain 2 Luminance, Gain 1 Red, Gain 2 Red and so on...
Now it is clear that I need two different sets of dark files for this, namely a set of darks for gain 1 and a different set of darks for gain 2.

And here the problem arises: If I put all darks into the main group, dss will stack them all together as it does only recognize different exposures but not different isos...

So the obvious way would be to use the dark 1 set in the Luminance gain 1 group and the dark 2 set in the luminance 2 group.

Unfortunately, once I have added the dark 1 set in the luminance gain 1 group, I can not add the same darks into the red gain 1 group again.

Apparently, DSS accepts the same file only either in one group only or in the main group where it is then used with all files...

This is some stupid bug.... please can you fix this?
Apparently, this was done to prevent users to add the same lights for multiple times into several groups. This may be reasonable but it should not prevent you to add the same dark and bias files into several different groups

Not completely respecting screen DPI setting?

I am running Windows 7 (all the latest service packs installed) under Parallels on a Mac Book Pro with a retina display which has a roughly 150dpi screen.

Certain elements appear to be half scale. The text in the command tab on the left is the correct size, but the width of the tab is about half the width it needs to be, truncating the right half of all the text in this tab. In addition, the file list tab, the text "Main Group" is half the size you would expect. All the rest of the text in the file list tab looks to be the correct size. Resizing the window does not correct any of this and the width of the command tab can not be adjusted.

In addition icons and triangular slider controls all appear to be half the size they should be, but are framed in a frame that appears to be the correct size. This is also the case in the RGB panel of the processing tab.

Pressing "Stop" button while stacking doesn't work

See post on DSS mailing list dated 27/07/18 at 05:11

Update CFitsIO to 3.51

https://heasarc.gsfc.nasa.gov/fitsio/fitsio.html

I noticed CCFits mentioned on here - is that likely to be helpful?

Decouple build from DSS as per issue 2

Checking some files makes comet tab disappear

I attempted to integrate some comet data I gathered last night.

Using 4.2.3 (and 4.1.1), when checking all files, manually marking comet (using shift) in first and last does not enable the comet tab. After laborious testing (over 100 files in just one tested channel), it seems that some files - consistently - make the tab not appear. There is nothing different about these files. I will upload screenshots and if you would like I could upload one offending file and one working file for you to examine.

Review items on #suggestions channel on Slack, Cloudy Nights, DSS mailing list etc.

And add as issues here as appropriate.

Black point and scaling issue

Hi,

I'm facing a strange issue where some of my DNG turn red within DSS. When used as calibration frames, this substract too much data from the final stack.
As discussed here, it has to do with black point and dcraw apparently.
Some of the DNG have an BlackPoint and BlackLevel EXIF tags set and some do not (why ? that's a mystery).
The consequence is that if "Set black point to 0" (-k 0) is checked, it overrides those EXIF tags and wrongly scale the image (from my understanding, I'm not familiar with raw usage).

For a good frame to come out of the process, dcraw must use the BlackPoint EXIF tag, or the -k parameter should be set to that value instead of 0 (which is the same as reading the value from the EXIF).
So, in my case I should always uncheck "Set black point to 0". Done. :)

But according to the manpage of dcraw, shouldn't the -D option be use to load dark frames anyway (as noted in the manpage at the -K option description) ?
Shouldn't frames be loaded as is without any scaling ?

Scaled bias frame, black

> dcraw -v -t 0 -4 -T "IMGP9837.DNG"
Loading Pentax K-5 II image from IMGP9837.DNG ...
Scaling with darkness 513, saturation 15867, and
multipliers 2.399911 1.000000 1.352119 1.000000
AHD interpolation...
Converting to sRGB colorspace...
Writing data to IMGP9837.tiff ...

Scaled bias frame, red

> dcraw -k 0 -v -t 0 -4 -T "IMGP9837.DNG"
Loading Pentax K-5 II image from IMGP9837.DNG ...
Scaling with darkness 0, saturation 15867, and
multipliers 2.399911 1.000000 1.352119 1.000000
AHD interpolation...
Converting to sRGB colorspace...
Writing data to IMGP9837.tiff ...

Bias frame, black

> dcraw -D -v -t 0 -4 -T "IMGP9837.DNG"
Loading Pentax K-5 II image from IMGP9837.DNG ...
Building histograms...
Writing data to IMGP9837.tiff ...

You'll find here a zip with the relevant test DNG files. Below are an extract of those DNG EXIF tags that seems to be relevant for the problem at hand

======== IMGP9834.DNG
Black Point : 67 67 67 67
Black Level : 67 67 67 67
Picture Mode : Manual, Off-Auto-Aperture; 1/3 EV steps
Exposure Time : 1/8000
ISO : 100
======== IMGP9835.DNG
Black Point : 129 129 130 129
Black Level : 129 129 130 129
Picture Mode : Manual, Off-Auto-Aperture; 1/3 EV steps
Exposure Time : 1/8000
ISO : 200
======== IMGP9836.DNG
Black Point : 257 257 258 258
Black Level : 257 257 258 258
Picture Mode : Manual, Off-Auto-Aperture; 1/3 EV steps
Exposure Time : 1/8000
ISO : 400
======== IMGP9837.DNG
Black Point : 513 513 515 515
Black Level : 513 513 515 515
Picture Mode : Manual, Off-Auto-Aperture; 1/3 EV steps
Exposure Time : 1/8000
ISO : 800
======== IMGP9838.DNG
Black Point : 0 0 0 0
Black Level : 0 0 0 0
Picture Mode : Manual, Off-Auto-Aperture; 1/3 EV steps
Exposure Time : 1/8000
ISO : 1600
======== IMGP9839.DNG
Black Point : 0 0 0 0
Black Level : 0 0 0 0
Picture Mode : Manual, Off-Auto-Aperture; 1/3 EV steps
Exposure Time : 1/8000
ISO : 3200
======== IMGP9922.DNG
Black Point : 511 511 513 512
Black Level : 511 511 513 512
Picture Mode : Manual, Off-Auto-Aperture; 1/3 EV steps
Exposure Time : 2
ISO : 800
======== IMGP9924.DNG
Black Point : 0 0 0 0
Black Level : 0 0 0 0
Picture Mode : Bulb, Off-Auto-Aperture; 1/3 EV steps
Exposure Time : 1.9
ISO : 800
======== IMGP9926.DNG
Black Point : 0 0 0 0
Black Level : 0 0 0 0
Picture Mode : Manual, Off-Auto-Aperture; 1/3 EV steps
Exposure Time : 2
ISO : 1600
======== IMGP9927.DNG
Black Point : 0 0 0 0
Black Level : 0 0 0 0
Picture Mode : Bulb, Off-Auto-Aperture; 1/3 EV steps
Exposure Time : 1.9
ISO : 1600

Regards

Upgrade libtiff to 4.0.9

This should be done as they have already addressed the 64 bit porting issue. The build for libtiff is designed to use command line tools. We should do that and just import necessary directories etc. as per issue 2

Warning: Do not use the llibtiff.org website - it is a very out of date clone of the real one.

The real current version of libtiff is here: http://simplesystems.org/libtiff/

Instructions on build for Windows: http://simplesystems.org/libtiff/build.html#PC

Write output FITS files in compressed format.

When specifying the name of the output FITS file to be created at run time, the user can indicate that images should be written in tile-compressed format by enclosing the compression parameters in square brackets following the root disk file name. Here are some examples of the extended file name syntax for specifying tile-compressed output images:

myfile.fit[compress]  - use the default compression algorithm (Rice)
                        and the default tile size (row by row)

myfile.fit[compress GZIP] - use the specified compression algorithm;
myfile.fit[compress Rice]    (only the first letter of the algorithm 
myfile.fit[compress PLIO]     name is required)
myfile.fit[compress HCOMPRESS]

myfile.fit[compress R 100,100]   - use 100 x 100 pixel tile size
myfile.fit[compress R 100,100;2] - as above, and use noisebits = 2

Option so that FITTs are stored and loaded “vertically mirrored”

Implement a Checkbox in “Options” >> “Raw/FITTS DPP Settings”, so that FITTs are stored and loaded “vertically mirrored”.
The Setting should be stored permanently in registry.
The reason is, DSS writes and reads FITTS-files vertically mirrored.
Fitswork for example has the same bug. (Some years ago the bug propagated in some Windows software because they copied it from an old version of Maxim).
There is only one correct vertical FITS orientation: the one used by all professional astronomy software. Correct software is Pixinsight and Astroart.

Thank You
Norbert

Save Picture to File should support 32 bit tiff

Both rational and integer formats.

Problem loading an already processed image with Processing/Open picture file...

If use Processing/Load a Picture File, It takes a VERY long time to complete (many minutes), The code seems to spend most of its time in CDeepStack::ComputeOriginalHistogram().

Once the image has completed loading the image display is not correct, and the histogram is also not correct:

If I open the same file using Registering and Stacking/Open picture files, it displays correctly.

dss does not recognize gain values in fits files

Hi, while dss does recognize different iso settings it does not show different gain values in fits files....
Can you fix this?

Upgrade from Little CMS (lcms) 1.16 to 2.9

http://www.littlecms.com/index.html

Add a License

Not including a license for the project makes it difficult for others to know how exactly the source can be used. Other who may also fork and create variations based on it (macOS, linux versions) would not know how their derived source should be licensed. You can easily add one as explained https://help.github.com/articles/adding-a-license-to-a-repository/

The *BIG* one 64-bit builds

Once we've upgraded the libraries we need we can undertake the 64 bit porting. The build tree is currently set up for this, so that shouldn't be an issue :). Many problems likely to bite us...

Decouple builds of external libraries from build of DSS

In order to make our life simpler, when we upgrade external libraries to a newer release the builds should be removed from the DSS Solution. The external headers and library files should be picked up by settings in the DSS project itself (include path etc..). If there isn't a newer release of the QHTML code available, then we should just decouple that build anyway.

libjpg, libpng, Zlib and others are being handled as sub-projects of QHTML - they should be built and used in the same way as other libs (IOW) in their own separate build process as this wil mean they are easier to upgrade.

Comprehensive Debug log

Feature Request:

1. Add a Debug Log function to DSS v4.x
2. Output ALWAYS GENERATED - so User doesn't have to re-run a problematic Session with Debug-Log=ON and hope for the same outcome as the original instance
3. Output Filename Timestamp-Coded and generated to one of a limited selection of Directory choices - Documents\DSS; or the Directory of the current DSSFilelist
4. Debug File contain readily human-readable format - CSV or JSON or simple XML - with data including timestamped rows of Terse-but-Understandable data
5. Debug File contain all Current Settings (superset of that recorded in the DSSFilelist file) accurate as of start of Register/Stacking action
6. Debug File contain a recap of the Host PC Resources available at start of Register/Stacking action
7. Debug File contain details for all the Filesets and Images actively selected for the current Register/Stack/Render including any pre-existing Registration data if not Register-already-registered-pictures
8. Debug File contain a pertinent recap of the internal actions performed per-Image and per-Action, as well as a recap of the resulting Data Values
9. Debug File Writes be performed in a most-conservative fashion (Write/Flush/Close and/or strong Exception Handlers)
10. New Debug File be started upon Clear-Filelist and Open-Filelist
11. Add "Report Issue" Support Feature (Menu Item in Help Menu)
12. Provide concise Step-by-Step instructions for reporting an Issue to DeepSkyStacker groups.io
13. Provide suggestion of how to Title the Topic to best gain Support attention
14. Provide DirectoryName for location of Debug File
15. Provide generic instructions for uploading Debug File to a Cloud File Share such as DropBox, OneDrive, etal (assume that Admin doesn't want these Files uploaded directly to Group.io if Forum License is based on Space Usage)
16. Provide "Debug File Package" generation support (consider generating a Compressed File Package - .zip or other OpenSource format), if multiple files (Debug File, DSSFilelist, AutoSave, minimal set of Lights, etc) are regularly part of the Support regimen

This is a Large Ask. With significant details. !!!

Stacking problem( canon 6d)

Hi!
The problem is as in the attached picture.
when I stack photos from a Canon 450 d, it's all good.
The problem occurs with the full frame Canon 6d.
Do you have any ideas?

Superbias: Add support to custom Master Offset/Bias

Hi, I'm trying to add a modified Master Offset/Bias in DSS, with no success.

My goal is to use DSS to generate the base Master Offset from 200 bias frames, and then clean it up using Gimp to generate a noise free version. I've got inspired by the Superbias algorithm from PixInsight. Although I have never used PixInsight, but I think I'm able to reproduce the clear output from Superbias with some procedural teps in Gimp.

I took this Master Offset/Bias generated by DSS from 200 frames:

(All images in this post are edited in Gimp to normalize levels).

And this is the result I'm able to produce in Gimp, which I'm calling Superbias:

(Both are bayer images, so these are just 25% resizes).

This is a 200% crop from the Master Bias:

And here's a 200% crop from the Superbias

Now, I'm stuck. I can't find a way to make DSS accept it as a Color Filter Array (CFA) image. Even Trying FIT files with the option to use them as a bayer image doesn't work. So I have no way to actually test if my Superbias offers any improvement over the original Master bias.

I created this issue firstly to ask for a way to use custom Masters in DSS. I can't find documentation online on how to produce a DSS compatible Master TIF. The EXIF from a Master file shows that there are 5 custom unreadable tags, which I cant copy to my TIF:

I believe this is part of why my TIF can't be recognized as a Master Bias file, even when I change the name, modification date and other EXIF fields to match the original. I just can't fool DSS into thinking my edit is a bayered Master Bias.

Secondly, I would love to see this clean up process included in DSS, so I would like to know if there are interest from the developers to implement this "Superbias" feature. Maybe there is already some progress in this direction. I was thinking about posting it as a online tutorial, but first I need DSS to support custom Master Offset/Bias.

Green channel clipping with Super-pixel and No White Balance Process options

Hi, I came across a clipping issue when testing the new 4.2.3 Beta 1 version.

Intro

I'm staking an Andromeda sequence shoot with my Canton Canon T3, using the Super-pixel mode, so the elongated stars can be found. I'm also using the new No White Balance Process option, which for the first time let me subtract the background color in Gimp correctly with no color issues. But I wasn't able to avoid clipping the Green channel. I'll tell my experience and show the issue.

Experience

My first time trying the Super-pixels and No White Balance Processing options combined led to a super-green picture, due to the non normalized addition of 2 green subpixels (I believe). I also had all "Color Adjustments" values set to 1 in "RAW settings", "Align RGB Channels in final image" disabled, and "No Background Calibration" selected in "Stacking Settings". The resulting image:

In this and next images, Gimp histogram is computed just for the layer with the 32bit unnedited DSS output. It also has a layer with the solid background color in Subtract mode (picked for each image accordantly), and a solid white layer in Dodge mode to brighten the image for preview purposes. These additional layers don't contribute to the histogram results.

As you can see, the background subtraction wasn't enough to correct the green value, as expected. So I used Gimp Levels filter to divide the Green channel by 2:

It fixed the green value, but I also could see some very subtle magenta tint in the blacks. So not a perfect result for the background subtraction in Gimp (maybe due to rounding errors?). The processed image has also a clipped Green channel, as expected.

I understood that I should get the Green channel right prior in DSS, so I played with the RAW settings and found out that setting Brightness to 0.5 and Blue and Red scale values to 2 did the job:

I expected this would avoid clipping the green channel. But despite the great results from the background subtraction in Gimp, for the first time finally delivering a true colourless background without artefacts, the Green channel was still clipped.

It led me to think the actual clipping is happening in the Super-pixel procedure. So to test that, I disabled the No White Balance Processing option, set all the "Color Adjustments" values back to 1, and got this:

As you can see, the Green channel came out with no clipping, but the background subtraction in Gimp wasn't enough to fix the incorrect white balance, as expected. If I set "Use Camera White Balance", I get a better white balance but equally incorrect background removal results in Gimp. So not the best option either.

Conclusion

I believe the issue is that Super-pixel results are being clipped, even when setting Brightness to 0.5, combined with the No White Balance Processing option. In the end, I would still use the clipped output, since it's the only way to get the perfect background removal in Gimp, and the clipping isn't even noticeable. But I hope this issue can be fixed by DSS.

Thank you for your time, and let me know if there are any thing I could do to help.

Windows XP Support

Hello,

actually, this is not a real issue (maybe, sending an e-mail would be more appropriate in this case, however, I seem not to be able to find one, so I decided to create an issue.

A close relative of mine needed to run DSS on a machine with Windows XP. I decided to port DSS to thsi system and I seem to be successful so far. Code modifications related to this case are relatively insignifficant. I would create a pull request for this, however, I had to make several other changes:

• I had to do some small modifications to compile the VS solution on my machine.
• Since the system on the target machine is quite out-dated (and XP updates are no longer being shipped for XP home users, with several exceptions), I had to link DSS' executables statically because I had been unable to install necessary redistributable packages or use the runtime and MFC DLL(s). Of couse, it is not a problem to change the linking to dynamic again.
• Because of the previous point, I included sources of external libraries, such as zlib, in my DSS fork. They needed to be linked statically with the runtime too.
• I changed the structure of existing projects a bit (e.g. exporting common settings to a property sheet file, moving public headers of the libraries to an include directory global for all projects).
• I changed the platform toolset to "Visual Studio 2017 – WIndows XP".

The fork may be found on my Gihtub. If you were interested in somewhat merging my changes to your repository, I would be glad to help. I will probably make some changes, since my fork was tested in the Win32 | Release configuration settings only, however, that should be minor ones. In any case, I plan to keep the XP support as long as possible/necessary.

Martin

Idea: Trying to use DSS-live is burning my eyes

I think DSS-live should have a dark theme..

I use it near my scope while taking subs and it scorches my vision at night.

Importing/building project guide

Hello, first of all, thank you for open-sourcing this piece of software!
I wanted to learn C/C++ a bit and I thought that at least reading code of application I'm often using would be helpful. I tried to build DSS, so I imported it in Visual Studio Community 2019 via Git, but I'm stuck with this error:

Error CMake Error at C:\Users\pawel\Source\Repos\DSS\CFitsIO\CMakeLists.txt:147 (FILE):
  FILE COPY cannot find
  "C:/Users/pawel/source/repos/DSS/CFitsIO/testprog.tpt".	CFITSIO	C:\Users\pawel\Source\Repos\DSS\CFitsIO\CMakeLists.txt	147	

at this line:

FILE(COPY ${CMAKE_SOURCE_DIR}/testprog.tpt DESTINATION ${CMAKE_CURRENT_BINARY_DIR})

Would it be possible to add a build guide to this repository? I think it'd be helpful for beginners like me.
Cheers!

New installer that will install 32-bit or 64-bit executable as appropriate

Subject says all :)

Compute Offsets progress dialog issue

Dialog almost immediately shows 100% completion on last light file to be processed even though the process of computing offsets is clearly not completed as the dialog is not dismissed for quite a while (in a Debug build a VERY LONG TIME INDEED).

Install option file location

I would like to have an option to install DSS and have it run from a user selected location other than the C: drive.

Add support for mono-modded DSLR's

For those of us who own color DSLRs that have been converted to monochrome, it would be nice to be able to process the RAW images without the debayer functions getting called.

Currently, the workaround is to export tiff files with dcraw -E -4 -T <filename> then load those into DSS.