DeepSkyStacker 4.2.5 is now available

[perdrix]

I've just released DeepSkyStacker 4.2.5.

You can get it from here: https://github.com/deepskystacker/DSS/releases/tag/4.2.5

Please note that version 5.1.0 of DeepSkyStacker (when it is finally released) will not run on 32 bit systems or Windows XP.

Here's the details of the the changes in this release and in 4.2.4:

Here are the main changes that were made for DeepSkyStacker 4.2.5

1. Remove use of predictive compression for TIFF files. Use of this revealed a long standing bug in Photoshop which was able to read the files created by DSS, but then wrote corrupt TIFF files.
    
2. Correct a problem where DSS failed to read files whose path contained accented characters.
    
3. Fix for a problem where DSS incorrectly reported master calibration frames from earlier releases as being incompatible when a user specified CFA pattern was used for FITS files.
    
4. Fix a bug introduced in 4.2.3 which causes the code to crash when moving the sliders on the processing page.
    
5. Apply a development fix to the LibRaw code which was looping forever attempting to open corrupt CR3 files.

Here are the changes that were made for DeepSkyStacker 4.2.4.

1. LibRaw updated to 0.20 providing support for over 1300 cameras including Canon Eos R (.CR3 files). CR3 file extension added to list of raw file types.
   
   ***** WARNING ***** WARNING ***** WARNING ***** WARNING *****
   
   LibRaw 0.20 has introduced a change that primarily affects users of "older" Canon DSLR cameras and FujiFilm X-Trans series cameras (older includes the EOS 60D and 60Da)!
   The change is to increase the size of the frame area of the image that surrounds the "user area" so that top and left margins are an even number of pixels. The resultant image that DSS extracts from the RAW file will be reduced in width, height or both by one pixel. As result the Bayer Pattern (CFA) used for de-Bayering the image also has to change.
   Unfortunately the LibRaw developers won't say exactly which cameras this change applies to save to say that it is not a large number. Other have reported that at least the following cameras are definitely impacted by this change:
   
   EOS 1D Mark IV
   EOS 5D Mark II
   EOS 7D
   EOS 60D
   EOS 550D
   EOS 600D
   EOS 1200D
   
   If your camera is one of those affected, you will not be able to use any existing master frames produced with DeepSkyStacker 4.2.4 Beta 4 or earlier releases as they will not be compatible. You will need to delete and re-create your master frames from the original darks, flats etc..
   I am sorry that this has happened, but it is outwith my control, and the LibRaw developers were not prepared to revert the change (they wouldn't even explain why they made the change). If there were another library I could use to decode raw images I would migrate to that but after researching it over the last several days I have come up with no viable alternative.
   ***** WARNING ***** WARNING ***** WARNING ***** WARNING *****
    
2. Fix to display Exposure, f-Stop, and ISO setting from EXIF tags in TIFF files.
    
3. Update libtiff to 4.1.0
    
4. Automatic detection of CFA matrix based upon FITS keywords such as BAYERPAT, COLORTYP, and MOSAIC (for Meade DSI colour cameras). The FITS File tab of the Raw/FITS DDP Settings dialogue has changed. If you de-select the tick box for: "Monochrome 16 bit FITS Files are RAW files created by a DSLR or a color CCD camera", then automatic detection will be used. You can override this by selecting this option and manually selecting the CFA pattern to be used. All the other settings on that tab are now always available for modification.
    
5. The exposure time is now correctly displayed for FITS files with the exposure time in microseconds (keyword EXPOINUS).
    
6. Display a warning message saying that DeepSkyStacker won't de-Bayer 8-bit FITS images.
    
7. Change code to read TIFF files in strips instead of by scanline. This can reduce the time to read the image by as much as a factor of 3.
    
8. Refactor the code to decode the TIFF file we just read and also use OpenMP. Time to decode the image reduced by about 4-5 times.
    
9. Refactor the code that writes TIFF files and use OpenMP to speed it up. Also write the output file in strips rather than scanlines and use TIFF predictive compression. Substantial performance increase.
    
10. Refactor the code that reads FITS files to make it easier to understand and also use OpenMP. Only a marginal performance benefit.
     
11. Major bug fix - calibration frames were either not applied or incorrectly applied when using Super-Pixel mode.
     
12. Change DeepSkyStackerLive so that the choice of using the Dark Theme is controlled by the user settings.
     
13. Display the FITS FILTER name in the picture list control, for information only at present.
     
14. Change the text used in the language selection ComboBox to always use Latin characters. This is a work around a problem with DLGINIT processing and Unicode characters.
     
15. Fix to correct problem where jpeg files were incorrectly identified as raw.
     
16. When FITS file auto-detection is used, the CFA Yes/No display was incorrect - now fixed.
     
17. Recommended Setting for Interpolation was incorrect.
     
18. Fix for crash while attempting to select comet.
     
19. Fix for Nikon Z 6, Z 7, and Z 50 being reported as unsupported.

Clear skies,  David

[davew]

Hi David,

Thanks for not only keeping DSS alive but for continually improving it. I noticed Ivo Jager being quite complimentary about the program and he seems to know a thing or two about Astro software 😎

Cheers,

Dave.

[perdrix]

Just a short post to advise everyone of a problem.  I fixed a problem in DeepSkyStacker 4.2.5 where DSS was failing to read files whose path or file name contained accented characters.

Unfortunately <BLUSH> I failed to fix the code for writing TIFF files, so DSS gets all the way to the end of the process and then fails to write the output file.

This will be fixed in the next version, but in the meantime please avoid the use of filenames or paths containing accented characters.

David

 

[happy-kat]

Thanks for the reminder of a later build. I'm hoping that item 18 might also mean that comet stacking on comet and stars dose now stack aligned to comet and stars. I hope so as it's missed.

[Stub Mandrel]

Cheers David.

May I add a sneaky feature request or two?

Can you make the graphs and sliders wider? Even if you don't change the resolution it would make them easier to use.

The other would be that if there are control frames of any type in both group 1 AND in any other group, not to combine them when  preprocessing the later group.

E.g. at present if I have subs and  a darks, flats and bias in Group 1 and in Group 2 I have subs and flats from a different evening, it will currently apply an average of both the group 1 and group 2 flats to the group 2 subs (as I understand it).

I know this can be avoided by butting darks and bias in group 1 and one set of flats and subs in each of group 2 and 3.

But it would be more intuitive if (say) I have set up a file list for a first session in group 1, then I just add any new control frames and subs for further sessions to later groups, knowing that any superseded flats, darks or bias will be ignored.

[almcl]

14 hours ago, Stub Mandrel said:

E.g. at present if I have subs and  a darks, flats and bias in Group 1 and in Group 2 I have subs and flats from a different evening, it will currently apply an average of both the group 1 and group 2 flats to the group 2 subs (as I understand it).

That's not quite how I understand it,  Neil.

May be into terminology differences here, but I think that only calibration frames in the Main group are applied universally.  So if you load lights, darks and flats into group 1 (confusingly, the second group tab) then they only apply to that group.  So with multi-session stacking perhaps one should only load offset files into main and put everything else in groups 1, 2, 3 &c? 

[Stub Mandrel]

3 hours ago, almcl said:

That's not quite how I understand it,  Neil.

May be into terminology differences here, but I think that only calibration frames in the Main group are applied universally.  So if you load lights, darks and flats into group 1 (confusingly, the second group tab) then they only apply to that group.  So with multi-session stacking perhaps one should only load offset files into main and put everything else in groups 1, 2, 3 &c? 

Sorry, I meant the main group, not group 1.

I do think it would be helpful and intuitive if main group control frames didn't get used if there are versions in one of the numbered groups.

Also, here's an issue I have encountered (the details are arbitary).

1. Night one I take 150 second subs, and make flats.
2. Night two, I take 300 second subs, but can use the same flats as nothing was changed.
3. A week later I take 300 second subs and new flats.

That means I need the same flats for sessions 1&2 and the same darks for sessions 2&3.

The problem is, I can't put the same flats into group 1 and 2; ditto I can't use the darks in two groups. The only solution is to make a master flat and dark and duplicate them. This is a bit of a pain.

It would be useful to be able to this as it often crops up when I try to combine data from earlier years with more recent data.

[almcl]

I think I can see the problem, perhaps worth raising over on the user group?

https://groups.io/g/DeepSkyStacker

[jjfabien]

Good day. I have just installed DSS 4.2.5 (I worked with the 4.2.4 previously) and I am now experiencing banding! Most images come out with circular banding. I don't understand where it comes from. Images were taken from a Nikon D750. Any idea how to solve this issue?

Kind regards
 

[happy-kat]

Are you using calibration files and if so are they old ones?

[Stub Mandrel]

22 hours ago, jjfabien said:

Good day. I have just installed DSS 4.2.5 (I worked with the 4.2.4 previously) and I am now experiencing banding! Most images come out with circular banding. I don't understand where it comes from. Images were taken from a Nikon D750. Any idea how to solve this issue?

Kind regards
 

Circular banding usually means stretching at too low a bit depth. Are you using JPEGs instead of RAW for your images or flats?