deepskystacker / dss Goto Github PK
View Code? Open in Web Editor NEWDeepSkyStacker
License: Other
DeepSkyStacker
License: Other
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.
If there's a newer release available!
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
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:
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
I would like to have an option to install DSS and have it run from a user selected location other than the C: drive.
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 ?
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.
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!
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...
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.
Hi, while dss does recognize different iso settings it does not show different gain values in fits files....
Can you fix this?
Before or after 64 bit???
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
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
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.
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.
Feature Request:
This is a Large Ask. With significant details. !!!
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
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
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
Hi, I came across a clipping issue when testing the new 4.2.3 Beta 1 version.
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.
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.
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.
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?
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/
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!
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!!!!
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
And add as issues here as appropriate.
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
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).
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.
I want to support Japanese. And I would like to contribute to Japanese language support.
See post on DSS mailing list dated 27/07/18 at 05:11
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
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
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.
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.
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.
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?
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
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
Subject says all :)
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.
Both rational and integer formats.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.