SharpCap Forums

I believe that in earlier Pro versions a change in the Live Histogram takes immediately effect.
Now the change appears after a stack is finished.
The time to really stack is a lot shorter then the sub exposure time.
So its very annoying to wait to see the result of a Histogram change.
Please can this be corrected?
Thanks in advance.

Hi,

can you just confirm for me what version you are using and what exposure length you have set. Also, are you adjusting the main live stack histogram or the mini histogram stretch in the controls on the right hand side?

cheers,

Robin

1. I was using the pro version 3.1.5098.

2. Sub exposure ranging from 8 s to 20 s (with ASI224MC).

3. Adjusting main Live Stack Histogram (the mini Display Histogram Stretch is reacting immediately).

Notes: test on different PC's (mini - laptop - desktop).
idem with "Test Deepsky Camera"
idem with version 3.1.5085
the stack itself is executed within ms

Hope this clarifies.
Regards.

Hi, this is not happening for me with 3.1.5108

My testing is with 'Test Deepsky Camera', 8s exposures, tried all the possible colour space options, tried combinations of aligning/not aligning and sigma clippign/normal stacking and I always see a quick response to dragging the stretch sliders or pressing the 'auto stretch' or 'reset' buttons.

The only time it doesn't respond for me is if I have just reset the stack and it is still waiting for the first frame of the new stack.

Note that the bigger your resolution, the less responsive it will become as it is more work to re-generate the display frame. I was testing with the sample M42 image (1280x960).

If you can still repro with the latest version then please send screenshots of your live stack and camera settings in case it depends on something I haven't thought of adjusting yet.

thanks,

Robin

Hello Robin,

Thanks responding.
In the meantime I've done some testing with the latest Pro version 3.1.5108.0
All went OK on my Desktop & Laptop.
Only at the miniPC (KODLIX AP42) I could reproduce the issue (I use this PC on the mount and control it using Windows RDP over WiFi).
I found the Windows process "TiWorker.exe" (Windows Modules Installer Worker) was producing high CPU resources.
The CPU was loaded at 100 %.
After stopping that service the histogram changes responded almost immediately.
I then started a bunch of other (astro-) programs to load the CPU, but SharpCap responded OK.
Normally I set the WiFi as metered but turned it off for carrying out some updates.
After the updates I did reset that and restarted the system.
So I am unsure why that service was still active (normally it is set to 'Manual').
When I have the opportunity to do some real observing I will further monitor the issue.
But for now all 'inside' tests where positive.
I'll report back in case I have further problems with this issue.
Thanks again for the excellent support.

Hi,

TiWorker is to do with Windows updates, so I guess that your machine had started to prepare for installing some updates which was using lots of the CPU time. Quite why it was running if you had disabled windows updates is harder to work out!

I'd expect this sort of behaviour on slow computers or with CPU being used by some other program - the stacking itself takes much longer so there is little CPU left over for the program to respond to slider movements.

cheers,

Robin

Robin,

I'm having similar problems with the live stack histogram updating right away on v. 5098 & 5108, didn't have the problem before these versions. When I first open SC the first object I live stack the histogram & AWB updates right away. When I go to the next object I lose the instant update for both histogram changes and AWB but it will update 1 or 2 sec after exposure finishes. The only way I can get back the instant updating is to restart SC and sometimes that doesn't help.

Don

UPDATE: issue not solved!

Did some other tests and it seems that this is a random issue.
Now & then the problem arises.
Up to now, I can't find a real cause.

I am having the same issue. I have been using Sharpcap for some time now with my zwo224/win10/ top end gaming laptop.....and I had NO ISSUES...last night for some reason the live histogram stopped working. Same as above posters. I need to wait until the frame stacks before I see any changes. This is aggravating. I have changed nothing for the past times out.
I also noticed a yellow script popping up now saying "Histrogram cannot be adjusted while viewing raw frames" when I have the individual frame pulled up and I touch the histo. sliders. I have NEVER seen that before???

I was using ..5108 version. I opened and closed several times. I uninstalled and reinstalled and the histro. was still messed up. I reverted back to ...5098 and everything was fine for about 20 stacks and saves..and then it happened again. I packed up and went in for the night...disappointed...and agravated.

I also noticed even after i uninstalled, my camera gain and exposure time was saved and put back in when re-installed??? is some fragment hanging around and haunting everything.

Hi,

sorry that this is still affecting people - I really don't understand the cause of the problem yet and it is one of the worst sorts of problem to fix - intermittent and does not cause an immediate crash

I need to find a pattern in the cases that are causing problems, so if you have problems, please can you report:

* Version of SharpCap
* Camera used
* Resolution and mode (ie RAW8 or MONO16 etc)
* Were darks used?
* Were flats used?
* System spec (CPU, number of cores, memory installed)
* Any other relavant info (worked for half an hour, then failed etc)

If anyone can repro the issue with the Deep Sky test camera the please let me know - instructions for making that happen would help me a lot.

Another suggesting is to see if 3.1.5059 works any better - that was the last build *before* I re-worked a big chunk of Live Stacking to deal with problems with flat frames not being applied. 3.1.5085 is the first workable build *after* that change. If 3.1.5059 is good but 5085 is bad then that would help me narrow down the cause of the issue. Of course the problem with an intermittent issue is that it will require quite a bit of testing with older versions to be sure it really has gone away

To be proactive I am going to put some logging into the next build to try to track the flow of the program through the live stack update process - this may help if I can then get a log showing the problem happening.

thanks for your patience,

Robin