Hi Robin,
A quick question about the live stack histogram drift tracking. When I use function at start of stack and set sliders on histogram where I like them. The black level slowly moves to the right. Am I doing something to cause this?
A slight possibility for a change in the livestack settings. The box that enables color calibration on start and periodic apply. You select how many frames between application. I think a time amount in maybe seconds might be an idea. I run sequence with 1 min between application regardless of sub length. When running short subs or longer the same delay between color applied occurs.
New Beta Update 4.2.14901
- admin
- Site Admin
- Posts: 17354
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: New Beta Update 4.2.14901
Hi,
it's fairly much expected that the use of the 'Track Histogram' feature will gradually move the black level to the right. When you start a stack with just one or two frames, the stacked image is noisy, so the histogram peak is quite wide. As the stack progresses and more and more frames are added, the noise level in the stacked image reduces, which leads to the histogram peak gradually narrowing - if conditions are constant then the actual peak point will remain pretty much in the same place and the sides of the peak will gradually move inwards.
The thing that the histogram stretch tracking is trying to do is to keep the image looking *roughly* the same in terms of brightness levels as the stack progresses. To a rough approximation, this works by keeping track of the fact that say 0.1% of pixels in the image are below the set 'black' level and moving the black level line to keep this correct as more frames are added. That means that as the stack progresses and the histogram peak narrows, the black level line will tend to move right while the mid level line may move left.
cheers,
Robin
it's fairly much expected that the use of the 'Track Histogram' feature will gradually move the black level to the right. When you start a stack with just one or two frames, the stacked image is noisy, so the histogram peak is quite wide. As the stack progresses and more and more frames are added, the noise level in the stacked image reduces, which leads to the histogram peak gradually narrowing - if conditions are constant then the actual peak point will remain pretty much in the same place and the sides of the peak will gradually move inwards.
The thing that the histogram stretch tracking is trying to do is to keep the image looking *roughly* the same in terms of brightness levels as the stack progresses. To a rough approximation, this works by keeping track of the fact that say 0.1% of pixels in the image are below the set 'black' level and moving the black level line to keep this correct as more frames are added. That means that as the stack progresses and the histogram peak narrows, the black level line will tend to move right while the mid level line may move left.
cheers,
Robin
Re: New Beta Update 4.2.14901
Robin,
Thanks for explaining how the tracking works. I didn’t realize the width of the histogram peak is related to noise level. I before the tracking function I used a sequence to periodically do an auto stretch to keep image brightness consistent ( using mode to adjust). The problem with this approach was the image was flat with little contrast. I really like the tracking function because I can set the sliders to get a great contrasty view.
Thank you for such a great product
Thanks for explaining how the tracking works. I didn’t realize the width of the histogram peak is related to noise level. I before the tracking function I used a sequence to periodically do an auto stretch to keep image brightness consistent ( using mode to adjust). The problem with this approach was the image was flat with little contrast. I really like the tracking function because I can set the sliders to get a great contrasty view.
Thank you for such a great product
-
cyrille.de.brebisson
- Posts: 69
- Joined: Sun Oct 01, 2023 4:42 pm
Re: New Beta Update 4.2.14901
Hello,
One request, would it be possible to add a UTC time display in the title or status bar? That would be SUPER useful!
Testing the latest beta:
- I love the "pink on active settings header"
- I love the arc" in focus
2 Bugs:
I had the title bar turning white in the middle of using sharpcap (while I was in dark mode)
I had the cursor on image stayed a right/left <> arrow. moving away changed the cursor back to a regular mouse pointer, but moving it back on the window turned it back in the <> arrow. I also had it turn into a vertical up/down at one point.
1 frustration thing:
In live stack, in town with lots of pollution, I got lots of notifications about too many pixels ignored due to sigma clipping. would it be possible to have an on/off option for this?
Thanks,
Cyrille
One request, would it be possible to add a UTC time display in the title or status bar? That would be SUPER useful!
Testing the latest beta:
- I love the "pink on active settings header"
- I love the arc" in focus
2 Bugs:
I had the title bar turning white in the middle of using sharpcap (while I was in dark mode)
I had the cursor on image stayed a right/left <> arrow. moving away changed the cursor back to a regular mouse pointer, but moving it back on the window turned it back in the <> arrow. I also had it turn into a vertical up/down at one point.
1 frustration thing:
In live stack, in town with lots of pollution, I got lots of notifications about too many pixels ignored due to sigma clipping. would it be possible to have an on/off option for this?
Thanks,
Cyrille
- admin
- Site Admin
- Posts: 17354
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: New Beta Update 4.2.14901
Hi,
An interesting idea on having a UTC clock visible somewhere - I will have to give some thought as to where it can go without causing problems...
For the title bar going white, had SharpCap stopped responding to keyboard/mouse briefly when that happened? If an application stops responding then Windows takes over drawing the title bar and frame of the window, allowing you to continue to move the window around, minimize it, etc even if it is not responding. However, Windows knows nothing about SharpCap's custom colour scheme, so it would draw the title bar in the normal colours. If SharpCap then finished what it was stuck on and started responding again, it would take over drawing the title bar again and it would return to the right colours.
The cursor is supposed to change over the image if you have the red 'selection area' box visible - when the cursor moves over the sides of the box then it should change to a left/right or up/down cursor (depending on which side). Other tools which show information over the image or allow you to interact with the image may also change the cursor.
I think that probably the sigma clipping warning is doing the right thing - letting you know that your sigma limits are too small and that significant areas of the image are being excluded on each frame. The things to try first are to increase the sigma threshold settings in the stacking tab (to 6 as a starting point, maybe higher) and/or increase the 'Sigma low limit (ADU)' settings. Increasing those will reduce/eliminate the warnings, and as long as the sigma clipping is still working for satellite trail removal adequately all is good.
cheers,
Robin
An interesting idea on having a UTC clock visible somewhere - I will have to give some thought as to where it can go without causing problems...
For the title bar going white, had SharpCap stopped responding to keyboard/mouse briefly when that happened? If an application stops responding then Windows takes over drawing the title bar and frame of the window, allowing you to continue to move the window around, minimize it, etc even if it is not responding. However, Windows knows nothing about SharpCap's custom colour scheme, so it would draw the title bar in the normal colours. If SharpCap then finished what it was stuck on and started responding again, it would take over drawing the title bar again and it would return to the right colours.
The cursor is supposed to change over the image if you have the red 'selection area' box visible - when the cursor moves over the sides of the box then it should change to a left/right or up/down cursor (depending on which side). Other tools which show information over the image or allow you to interact with the image may also change the cursor.
I think that probably the sigma clipping warning is doing the right thing - letting you know that your sigma limits are too small and that significant areas of the image are being excluded on each frame. The things to try first are to increase the sigma threshold settings in the stacking tab (to 6 as a starting point, maybe higher) and/or increase the 'Sigma low limit (ADU)' settings. Increasing those will reduce/eliminate the warnings, and as long as the sigma clipping is still working for satellite trail removal adequately all is good.
cheers,
Robin
Re: New Beta Update 4.2.14901
Hi Robin,
Getting live stack stretch tracking crashes in last two Beta versions. Had to go back to v4.2.15098.
Regards,
Don
Getting live stack stretch tracking crashes in last two Beta versions. Had to go back to v4.2.15098.
Regards,
Don
- admin
- Site Admin
- Posts: 17354
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: New Beta Update 4.2.14901
Hi,
yes, I'm aware of that issue and adding more checks in each new version to try to track down exactly where it is coming from - basically the stretch tracking is failing because the 'old' stretch data it is being asked to adjust is invalid (values that should all be in the range zero to one are sometimes less than zero or bigger than one). I'm trying to track down how those invalid values got there in the first place rather than just ignore them, as they might well be the symptom of some other problem that needs fixing.
I think that the next update due Monday has a reasonable chance of resolving the problem (or if not, extra checks should hopefully identify where the bad values are coming from pretty quickly).
thanks,
Robin
yes, I'm aware of that issue and adding more checks in each new version to try to track down exactly where it is coming from - basically the stretch tracking is failing because the 'old' stretch data it is being asked to adjust is invalid (values that should all be in the range zero to one are sometimes less than zero or bigger than one). I'm trying to track down how those invalid values got there in the first place rather than just ignore them, as they might well be the symptom of some other problem that needs fixing.
I think that the next update due Monday has a reasonable chance of resolving the problem (or if not, extra checks should hopefully identify where the bad values are coming from pretty quickly).
thanks,
Robin