12 replies to this topic

[otocycle]

I'm likely doing something wrong with Deep Sky Stacker 4.1.1 (settings), but after trying every obvious combination

to stack 275 FITS images, 11 hours total exposure for M101, the bit depth seems limited.  Tried to save as 16 and 32 bit

as well to no avail.

 

The same stack in Siril looks fine in post at 16 bits, so what am I missing ?   Here are the downsized/cropped examples from DSS

and Siril respectively.   Does DSS work better with TIFF input files ?   Any hints would be greatly appreciated....thanx !

 

Scope = Orion AG8

Camera = ASI2600 MC @ 1x1

Bayer setting = RGGB

DSS Stacking mode = Median and Kappa-Sigma (tried both)

DSS Intermediate/Output files = TIFF  (maybe should stay with FITS throughout?)

 

 

 

[rj144]

Just use Siril.

[archiebald]

Just use Siril.

Agree.  I started out using DSS and while it helped me in my learning phase, but then found that Siril does the job better and faster and if you wish you can either do fully automated stacking or do a full manual stack process to really refine (and learn) what is going on.

 

I deleted DSS from my Astro PC some time ago as it had outlived its usefulness for me.

[matt_astro_tx]

Yep, definitely recommend Siril over DSS.

[smiller]

+1 on SIRIL is the way to go, it’s much better and being very actively improved.

 

However we didn’t answer your question as to the mystery of DSS producing a limited bit depth image.  Certainly final stacking should be in 32-bit format.  Calibration is also often done in 32-bit although it can be done in 16-bit, but the final stacking should be in 32-bit.

 

I don’t know the exact cause but I ran into this before in a couple of circumstances, years ago with DSS.  In general even with DSS, using FITS files is better than TIFF files from my understanding as FITS more consistently holds some of the metadata (header data) that the stackers read.  That was my main mistake… occasionally not using FITS early on in my Astra photography journey.

 

I wouldn’t worry too much about the root cause of the problem, just stick with FITS, I would switch to SIRIL because it’s really just a much much better solution and see if it ever happens again.

 

Another cause of the problem and can be auto stretching. I have had a couple instances where the auto stretch, in Pixinsight in particular, would create an image like you display, which is technically referred to us posterization.  This sometimes happens when auto stretching an image that has had some other image processing steps on it, especially a noise reduction. Even on the same image not all auto stretching operations from all programs create this artifact.  I don’t know the reason this happens either.

Edited by smiller, 15 May 2025 - 03:00 PM.

[matt_astro_tx]

I think the OP is on the right track with bit depth. I’ve encountered similar when processing in 16 bit. So I stay in 32 bit now and haven’t encountered it again.

[Andros246]

I can’t say I’ve ever seen this issue

[otocycle]

Thanks for all the follow up....I agree that Siril is better for one-stop registration, stacking, and processing, but DSS still has its place for less overhead, comets, displayed header data, etc.   Been using DSS since 2008 and old habits die hard.

 

As for the bit depth issue, I went back and registered/stacked the same set of lights/darks/flats/biases on and older Windows7 workstation running DSS 4.2.6.   It took forever (5 hours), but the resulting Autosave.fit file did not have the posterization.   Only the saved 16 and 32-bit output files have this problem, so I need to figure out the disconnect for the FITS files and/or post processing program.

 

Here is the cropped autosave.fit as a jpg, and it looks OK to me.

 

 

 

[Jerdiest]

Glad to see someone else with this problem, as I have (I think, as far as I understand as a newbie) the same problem (see here, where i did not get many replies).

I take the general advice to use Siril, but it takes tons of harddrive space which I don't have on my laptop, and running it with files on an external drive is extremely slow.

 

So following with great interest here!

[otocycle]

Glad to see someone else with this problem...

 

I was happily working with RAW CR2 files from modified Canon DSLRs for many years without any DSS issues with TIFF output files.  Began using Siril last year and the required working space was astonishing (can be helped by using "Developer's Mode" in Windows).   Then I upgraded to the ASI2600MC Pro camera and began working with even bigger FITS files (50Mb each) and had this problem with DSS.   Workaround for me is to use the Autosave.fit file instead of a saved 16/32 bit FITS file.

 

I immediately ordered bigger SSDs to upgrade storage size for Siril working space on the desktop and laptop.   The new drives arrived yesterday ! 
 

Edited by otocycle, 16 May 2025 - 04:45 AM.

[smiller]

Thanks for all the follow up....I agree that Siril is better for one-stop registration, stacking, and processing, but DSS still has its place for less overhead, comets, displayed header data, etc.  

 

 

I take the general advice to use Siril, but it takes tons of harddrive space which I don't have on my laptop, and running it with files on an external drive is extremely slow.

 

Yes, the high use of intermediate disk space is an issue.  There are a couple ways to reduce it in SIRIL:

 

1) set precision to 16 bits for every stage except for the final stacking and then you set 16 bits. This used to be the default for SIRIL but they changed it to 32 bit all the time.  There is no loss in quality to have the calibration steps at 16 bits because your individual lights are at 16 bit resolution, at most, in those stages anyway.

 

2) you can also turn on RICE compression.  It is lossy, but it’s near lossless and I have tested it and it does not degrade quality in its default setting for quantization.  I have done a significant amount of side-by-side testing and I have never detected a loss in quality.

 

Here are two threads that touch on these:

 

https://www.cloudyni...s#entry14001078
https://www.cloudyni...siril-stacking/

 

Also, although this isn’t a SIRIL thing, you can often store your lights with compressed FITS using lossless RICE compression depending on your capture program.  Nina supports capturing in this mode and programs like SIRIL and Astro pixel processor directly read these compressed FITS.   I find this compression saves just a little bit less than 50% of the space.  Some digital camera manufacturers also have their own proprietary lossless compressed RAW format, and those can often be read by stacking programs also.

Edited by smiller, 16 May 2025 - 11:35 AM.

[rj144]

I was happily working with RAW CR2 files from modified Canon DSLRs for many years without any DSS issues with TIFF output files.  Began using Siril last year and the required working space was astonishing (can be helped by using "Developer's Mode" in Windows).   Then I upgraded to the ASI2600MC Pro camera and began working with even bigger FITS files (50Mb each) and had this problem with DSS.   Workaround for me is to use the Autosave.fit file instead of a saved 16/32 bit FITS file.

 

I immediately ordered bigger SSDs to upgrade storage size for Siril working space on the desktop and laptop.   The new drives arrived yesterday ! 
 

I'm confused at the Autosave.fit file.  What exactly are you doing there?  The final stack is just one file so how are you saving space?

[otocycle]

I'm confused at the Autosave.fit file.  What exactly are you doing there?  The final stack is just one file so how are you saving space?

Sorry, I should have been clearer that I used the automatically DSS generated, post stack Autosave file (this is an option in DSS) to get around the bit depth/posterization issue from above.   The only space saved would be from not saving an additional 16/32 bit output file as TIFF or FITS.