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

[perdrix52]

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.

[tonk777]

Isn't the second image shown also modified by the gamma slider to its top right? Move that slider about an see the image gamma change. So what you see is happens to be where ever the gamma slider is set.

[perdrix52]

Yes it is but the bottom image shown is with the default gamma and is shown as it appears in other stuff like PS or GIMP. The upper one shown is when loading into the postprocessing and a gain up is applied prior to display which isn't necessarily wanted ...

[tonk777]

I expect Luc can give the underlying reason and work flow. From experience this is what I have observed

After after initial stacking there is no stretch yet applied so most stacked images written out look black with a few stars - the data is still linear. This is how the image should look when loaded into the post processing window - black with a few brighter stars showing up. The gamma slider provides a display only stretch so you can see something of your stacked image. (in fact over the years on CN the most frequent new user issue is that they see a reasonable on-screen display but when they open the resultant written out file in something else they see near black. The response is always - "you have linear data - that is normal and expected - you need to do your own non-linear stretch in an application of your choice"

So the issue to sort out is - when is the DSS display really reflecting the content of the file and when its it applying a display only stretch of some sort as an visualization aid.

---

[[My own thoughts are that the DSS post processing tools are very weak and if used compromise useful post processing in other image processing tools (compresses dynamic range in the wrong places and this cant be recovered). This can be improved. There are at least two standard astrophotography non-linear transformations that could be incorporated into DSS that would improve this situation - DDP and ASINH - the former models chemical film processing and development while avoiding luminance saturation and latter similarly stretches but preserves the original colour balance. These would at least give the user the right leg up from linear to non-linear processing and deliver an image that looks right on both DSS's display and in other programs]]

[tonk777]

This is just a rough idea - could we not use mouse rollover to show the real untreated image (mouse off) and the temporary gamma treated for visual aid version (mouse over)? That or an explicit toggle button.

[perdrix52]

I just think that to start with the post processing screen should not apply any gain until asked to. FWIW I believe that Luc is somewhat in agreement on this.

As for other post processing tools did you not notice my suggestion on Slack to incorporte the processing engine from FITS Liberator which does ASinH and a slew of others in a readily understandable way.

Dave

[tonk777]

Why not simplify this even further and just have DSS launch FITS liberator with the final stacked image to do the post processing steps - saves a lot or work and there is a familiar UI to use.

[tonk777]

Actually that might not be a good idea re the FITSLiberator app. FITSLiberator is open source on GitHub and unfortunately its not been touched since 2011 - it looks dead in most respects. The last commit is a tweak to the README 3 years ago and prior to that the NSIS installer script was tweaked 6 years ago. The code itself is frozen for 7 years.

I like the idea of using the engine for various post processing things - but if we take this approach we should fork what we need into the DSS code base and maintain what we use for ourselves - no-one else is going to fix it in FITSLiberator land. I've grabbed the code to a local place and going to get it building in VS2017

[tonk777]

I just think that to start with the post processing screen should not apply 
any gain until asked to. FWIW I believe that Luc is somewhat in 
agreement on this.

Which was my view too - as I said the biggest complaint from first time CN users of DSS over the last 10 years or so was the file you saved when opened elsewhere never looked like the image shown on the DSS display (due to the temp contrast tweak) and it was (correctly) too dark to see anything. Once they understood that they had to do a stretch themselves things settled down.