Ability to "Lock" t...
 
Share:
Notifications
Clear all

2026-10-09 APP 2.0.0-beta48 has been released !

This is mainly a bug fix release for the reported bugs in beta47. In addition it has a significant User Interface performance improvement noticable when you need to process 1000s of images in APP.

2026-10-03 APP 2.0.0-beta47 has been released !

This is a very big release... many code optimizations/rewrites, many parts of APP are much faster and more precise, especially star analysis and registration are much faster ! Big mosaics will go much faster 🙂

And we introduce a new preview filter, which includes the new Adaptive Deep Sky Stretch and a General Levels Stretch, this has been long over due. The old preview filter (the panel on the right side to stretch and preview your data) has not been updated for a couple of years and it is a critical part of any APP session.

Adaptive Deep Sky Stretch or ADSS is a much more intuitive stretch algorithm. It is also color preserving (which is a great new addition in itself ! ) which means that the highlights are no longer bleached, color is maintained from the linear data while stretching. You can simply stretch your data using the sky background level and signal width sliders which work much easier and more intuitive. You no longer need to fiddle with the old complicated sliders with zoom buttons. All the zoom buttons for the sliders are made redundant. And you can enter slider values in the slider value fields yourself. I will make a youtube video in the coming days to explain and fully introduce ADSS. Once the video is ready, it will be highlighted on the forum.

RGB Combine upgrade !. The RGB Combine Tool has been rewritten mostly. The tool is faster and easier to use and most importantly, the Luminance slider to inject a luminance channel or channels into the RGB composite is now working correctly. It no longer bleaches the RGB colors. Combined with the new ADSS preview, you will get much better and easier great composites with great color! I will also explain this in a new youtube video.

Ability to "Lock" the stretch value of the DDP preview filter

8 Posts
2 Users
3 Reactions
4,185 Views
(@scott_rosen)
Neutron Star
Joined: 9 years ago
Posts: 59
Topic starter  

Hi Mabula -

APP's auto DDP stretch works really well for showing the image.  If I recall correctly, I think you have it set to stretch the image based upon the level of noise in the image.  Because of this, one thing I've found a little difficult to do is to compare different images in the Image Viewer.  For instance, if I want to compare a linear image to the calibrated version, the stretch changes (the calibrated version usually has a more aggressive stretch) so the improvement from calibration isn't as straightforward to see (i.e., it doesn't necessarily look less noisy due to the more contrasty stretch).

I think it would be useful to have the ability to do an Auto DDP stretch and then click a button that "locked" those stretch values until the lock button was unchecked.  That way, when I move from one sub to another or one version of a sub to another, the stretches are identical and the differences between the two images is more clear.

Scott



   
Mabula-Admin reacted
ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 9 years ago
Posts: 5420
 

Hi Scott,

The auto DDP stretch uses the dispersion (width of the histogram peak) and lokation (the ADU value of roughly the peak itself) of the histogram to stretch the data. Noise and dispersion are correlated to a high degree, so you could say that the stretch is based on the noise in the image.

Indeed, you suggestion is very usefull and this can actually be done with the preview filter.

app preview

If you disable the "auto" selectbox, the stretch parameters are "locked". If you switch then, for instance, from linear to l-calibrated in the image viewer, the stretch parameters won't change. If you need to have APP do a new automatic stretch, just switch the "auto" selectbox on again.

Let me know if this works 😉

One other suggestion/tip to make full use of this: if you have normalized your frames, then with the l-c-r-normalised image viewer mode you can check how good normalization is working. Load a normalized frame with auto ddp (or adjust the parameters manually), then turn off auto. If normalization works correctly, if you load another frame which had a different background value and/or dispersion, you should see that this is now normalised. The normalization adjusts the background and dispersion so it becomes equal for all frames. Another way to say this: after normalization, the histogram peaks and widths should be the same. By disabling the auto DDP, you can verify this yourself.

Mabula

 



   
ReplyQuote
(@scott_rosen)
Neutron Star
Joined: 9 years ago
Posts: 59
Topic starter  

Hi Mabula - that seems to work - sort of.  If I load a sub into the image viewer and then turn off auto, it seems to hold the same stretch for similar subs.  However, when I then move to the stacked image, it does a more aggressive stretch - even though I have auto disabled.  It seems as if it'll "lock" the stretch until it comes across an image with significantly different dispersion.

Or, perhaps I'm still doing something wrong?

Scott



   
Mabula-Admin reacted
ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 9 years ago
Posts: 5420
 

Hi Scott,

I think something else happens. I know that the stretch certainly stays fixed with "auto" DDP deselected. When you compare a regular frame with a stack, chances are big that the stack has the peak at a slightly different ADU value. It should have the same ADU value as the reference frame though. A small difference in ADU values of the stack's histogram peak compared to a linear light frame's histogram peak could cause the stretch parameters to give the impression that the stretch is different. The stretch is the same, the problem is the black point. If the lights aren't normalized we don't have a guarantee that the blackpoint of the fixed stretch "works".

Also when you move from a 16bit light frame to a 32bits integration frame, the parameters are dynamically scaled to preserve the stretch for the other data range. So this shouldn't be the problem either.

The best way to verify that it's working correctly:

If you load the lights after normalization with the l-c-r-normalized image viewer mode and compare those to your integration, then the fixed stretches should really match, since all light frames are normalized then and should have the histogram peak ADU value and histogram width the same, as does the stack.

Let me know if this is clear 😉



   
ReplyQuote
(@scott_rosen)
Neutron Star
Joined: 9 years ago
Posts: 59
Topic starter  

Hi Mabula - I see what I was doing wrong.  I was comparing the linear image to the integrated image, so it hadn't been normalized.  Once I compared the l-c-r-normalized versions to the integrated, the brightness levels seemed very similar.  So, the unchecking "auto" does do the "locking" of the stretch value that I had requested.

Thanks for your explanation and pointing me in the right direction.



   
Mabula-Admin reacted
ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 9 years ago
Posts: 5420
 

Great Scott 😉

I think it is very useful to be able to visually verify how good (or not) normalisation is working using the l-c-r-normalised mode and ddp auto off 😉

Cheers

Mabula



   
ReplyQuote
(@scott_rosen)
Neutron Star
Joined: 9 years ago
Posts: 59
Topic starter  

Hi Mabula - I'd like to revisit this topic and make a suggestion.  The behavior that still seems odd to me (at least not what I suspect) is that APP applies different stretches (different stretch values) to the data after the auto box is unchecked.  I understand that there are differences in brightness levels in images that are linear versus, say, a normalized stack.  And, I do see APP changing the stretch values when I switch between a linear image and a stack (just as an example of one type of comparison).  But, to me, it's more intuitive that once I uncheck the Auto box, the DDP values should not change no matter what I choose to display in the preview window.

In other words, if I've auto DDP'd some image and APP has selected good DDP stretch values, once I uncheck Auto, APP should ONLY display the next image and apply the exact same stretch.  So, the auto button will always provide an "optimized" stretch for the current image.  But, once the auto box is unchecked, the stretch should be "locked" - no matter what.  After I check auto again, APP should do an auto stretch on EVERY image I load into the preview window until I uncheck it again.

That's the behavior that I expect to see.  There may be good reasons why the behavior should be different, but I suspect others may expect the DDP stretch to not change if auto is not checked.

What do yo think?

Scott  -   http://www.astronomersdoitinthedark.com/



   
ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 9 years ago
Posts: 5420
 

Hi Scott,

I think the issue is that a stretch consists of 2 things,

  1. finding a suitable black point and
  2. finding the non-linear stretch parameter.

If data is loaded unnormalized, then due to changing background values between the images and the AUTO DDP set to off, the black point value that stays fixed (because part of the DDP settings) will most likely not be suited to another image due to a difference in background value. So if you load the images normalised, then this problem should be gone and it should work like you would expect it to work. It really is one of the main reasons of the normalised image viewer mode to be able to do this correctly.

And when you enable the "auto" DPP again, it should recalculate new DDP settings for the image in the image viewer (if DDP is on). Does it not do this?

That's the behavior that I expect to see.

You should have this behaviour with the image viewer mode l-c-r-normalised. It's one of it's main purposes, to be able to compare images in a normalized way with the same stretch applied by disabling the auto DDP setting.

With the image viewer modes without normalization it would only work if by chance the images would all have the same background value, which most likely, is hardly ever the case.

Does this clarify the behaviour?

Mabula



   
ReplyQuote
Share: