Where next ...

[perdrix52]

This is a tracking issue for use only by the development team to list possible future enhancements:

• Collapse StackingDlg::OnAddxxxx() member functions into ONE mf() - WAY to much code duplication and opportunity for copy/paste errors.
• Upgrade build environment to VS2022, Qt 6.5 (adds Themes)
  Update to toolset V134 completed, Update to C++20 done, waiting for Qt 6.5 fixes and and Visual Studio fixes
• Reinstate a "Properties" window for image list control to allow changing Type, ISO and Exposure as before.
• Dark Theme support - needs Qt 6.5
  Initial code changes done, awaiting fixes to Qt and Visual Studio
• Update CFITSIO to 4.2.0 from 3.43
  Also updated ZLIB to 1.2.11
• Add FITS header keyword NCOMBINE to output FITS files (number of images in stack). Display as for TIFF
• Issue Comprehensive Debug log #22
  Could be partly/entirely based on existing trace code
• Convert help from existing Windows .chm to Qt help.
• LRGB and narrow band stacking.

Comment from Tony Cook:

The existing group feature should be the jumping off point for handling the calibration of L,R,G,B channels,

The addition of narrowband channels should also be considered. This should include options for the standard Ha, OIII, SII, NII named filters but should also include the ability to create custom named channels (e.g. I use Semrock CN, CO+ and C2 filters for comet imaging, but others might be using red continuum and other specialist AP filters)

Finally (as mentioned above) to complete this feature there has to be a channel mixing tool. For example it could be modeled on Images Plus interface as this is quite simple (we would have DSS group(s) to output LRGB channel assignments each with 0 - 1 weightings). It would be nice to be able to do the channel mixing in (near) real time.

Comment from Robert Pascale

I like this request, but I think there is an interim use case that might be beneficial.

When importing the images, use the FILTER to split the images in to groups (if you could name the groups to make it easier to identify, that would be a bonus).
This would simplify having to go through and pull each sub type and put it in to different groups manually.

When stacking, I will select a reference image (in one group) and then stack all images in that 1 group (eg my Red filter) and save the image as my Red stack.
Then, leaving the reference image the same, uncheck all the images in Group 1, select all the images in Group 2 (eg. Green filter), stack them to produce my Green stack.
Then rinse and repeat for Blue and H-alpha.

The above process is a bit of a click fest, interrupted by waiting for each stack to process, and is therefore error prone.

If the resulting process could all be done "at once", and then the autosave files could be named something like autosave<group-name(filtername)>. Then the resultant files could be dragged in to another program to combine and edit.

The above feature request is mostly within the scope of DSS as a file processing workflow enhancement, not so much as adding to the complexity image processing itself of combining the various channels to a single image (eg. in my use case, if you merged the RGB channels, there's be the left over luminance channel)

• Astrometric registration. This may be useful and or necessary for stacking multi-scale images.
• Stack multi-scale images:

From HenkSB ([email protected]) One idea would be to stack the sets of subs in their own individual groups then use plate solving to find the exact scale and angle factors. Use the lowest resolution stacked image as a reference and scale the high resolutions down to it using the scale factors. Then use DSS to stack once more - this time the per-group stacked images.

Adding a plate solver is hugely inconvenient of course with maps and all. DIY plate solving is simpler to implement than a completely blind plate solver because we only have one map, namely the lowest resolution image. It is likely that the higher resolution images fit within it, so create a quad hash table of stars for it to be used as the map, and one for each higher resolution. Then calculate quads for the other images to find the scale and rotation factors. To be honest I just read up on this, looking at steps 3 and higher of https://olegignat.com/how-plate-solving-works/

If an optimal preconditioning is needed before stacking the plate-solved group stacked images, implement a 2D Poisson resampling algorithm based on the scale factors so DSS does not have to rotate over ridiculous angles. For work I have implemented 1D resampling of Poisson data, but 2D is much harder. Not impossible though.

It's easy to make simple requests that are difficult to implement, I think this is one of them. Some of it sounds fun to prototype in Scilab but translating it to C++ is another story. And of course, adding the camera characteristics per group, I think currently it is probably just one. Maybe there are public domain codes that already do this. If I can help let me know, I could prototype some if you think it has merit. Clearly, it's not a simple task.

Martin Toeltsch said: What I can imagine is this:
DSS just assumes that the frames of different resolutions show similar areas of the sky. Then we rely on our Matching-Stars algorithm (just as now for all the frames of same resolution) to find the proper shift/rotate. We do this after downscaling of the higher-resolution frames to the lower resolution. It's the user's responsibility that all frames show similar details of the sky. If not, he/she shall not be disappointed about bad results.
Darks/flats/offsets will be applied only to those light-frames with identical resolution. So we should probably not allow more than 2 different resolution at all in one group.

• Support of Astro-TIFF
  See https://astro-tiff.sourceforge.io/
• Debayer of OSC TIFF Images

Added support to TIFFUtils to Read and Write TIFFTAG_CFAREPEATPATTERNDIM and TIFFTAG_CFAPATTERN which are defined in the TIFF/EP standard. The only TIFF files DSS writes with a CFA pattern are the master flat and master offset files. This requires an update to SharpCap to write the TIFF files with these tags. Will look at re-using the same logic for manually setting CFA as for TIFF files.

• Add option to RAW/DDP settings to permit reading of camera RAW as monochrome images (i.e. don't de-bayer).
• Comet stacking issues:
  Raised by Ray Butler in this topic: https://groups.io/g/DeepSkyStacker/topic/comet_algorithm_bug/96837388
  Martin Toeltsch has started on the Comet Position interpolation/extrapolation code
• Validate existing Per Channel Background Calibration and RGB Channels Background Calibration code

My gut feeling is that they aren't quite right because I don't think that adjustment of the background level should render the final stacked image as monochromatic as it seems to.

• Add option to FITS/DDP settings to read FITS vertically flipped

• Add option to either FITS/DDP settings or to Stacking Settings/Output tab to write FITS vertically flipped.

• Issue DSS freezes upon generating a Star Mask and changing the extension to FITS #91

• Add a powerful automatic stretching method to the final image post processing dialog.
  E.g. a arc-sinh stretching, and/or a auto-stretching based on histogram.

• Improve performance of "calculate offsets"

• Improve performance of "Smooth out" at the end of "Stars+Comet" stacking.

• Improve performance of file IO through concurrently reading/writing the next file while processing the last one.
  Writing the temp files after stacking
  (Reading the temp files while generating the result brings no speed improvement.)

• Visual indicator of automatically selected reference lightframe in the file list file as well as GUI. This is hard to do without breaking compatibility - so we may reject it.

• Bad pixel map to set known bad pixels to (e.g.) all zero or high values).

• Ignore brightness-, red-, and blue-scale factors for RAW and FITS flat-frames

• Provide option to suppress File has already been loaded message. QErrorMessage perhaps.

• Add an option to disable "normal" rather the error condition beeps.

[markmac99]

For platesolving, I'm not sure i see the benefit but you could investigate the online capabilities of nova.astrometry.net. I have a (python) example showing how to use astrometry.net to platesolve but its pretty straightforward - you upload a set of x/y star coordinates and an approximate FOV range (say 2-10 degrees) and you get back the RA/Dec of the centre plus the image scale. orientation, and fields of view (horiz + vert). Seems to me DSS probably has the required info already.