Sharpcap sequence calibration preprocessing issue

[TimAldworth]

I am running SharpCap v4.1.12529.0 (X64, 64 bit), on a recent Windows 11 Asus laptop.
Mount: iOptron EQ45-Pro
Camera: ZWO ASI533MM-Pro; [OAG] Guide Camera: ZWO ASI120MM; Telescope: William Optics GTF81; Filter Wheel: ZWO EFW 7x36mm [L,R,G,B,Ha,Oiii,Sii].
I have just started using the Sharpcap 'Deep Sky Sequence Planner'. I have elected to perform Dark frame subtraction and Flat frame application at run-time. The sequence runs well, configuring the mount, EFW, camera as required. However when inspecting the [Calibrated] image frames on FITs Liberator, it appears as if a number of the frames [5% to 40% on some sequence runs] have an exposure issue, where the top of the frame is lighter, or darker than the bottom, the split being horizontal at a variable distance from the top of the frame.
I have simplified the sequence run to create 50x, shortish [0.125s to 8s] exposures with each of the LHOS filters on a blank target [sheet over the telescope objective with even illumination]. This will use the individual filter Flat Frames [LHOS] and the Dark frames [2s to 8s].
I have tried using UAB2 cable instead of the usual USB3, to attempt to slow the process, to no avail.
I have attached the Sharpcap log file; jpg screenshots of 2 affected frames and 1 good frame to compare with, also the 3 x camera setting text files.

When I remove the application of the Flat/Dark frames from the test sequence, then run the test sequence, all 100% of exposures [200/200] are perfect when inspected in FITs Liberator.
This appears to be an issue when applying the calibration [Dark or Flat] frames during the sequence run, but only for a small proportion of the frames.
I think I have eliminated the calibration frames themselves, as most of the calibrated light frames are good.

[admin]

Hi Tim,

sadly it looks like your attachments have gone missing, so probably worth having another go at posting those - it sounds like they will help me understand the issue in more detail.

I have seen issues with glitches in image data coming from the camera that sound similar to your issue, but it seems odd that they would only happen while the dark/flat correction is enabled in SharpCap (unless the extra CPU load has something to do with it). The first thing I would try in this situation is to turn the 'Turbo USB' setting for the camera to minimum value and see if that helps.

cheers,

Robin

[TimAldworth]

The 'Lost' attachments, hopefully [Reduced from 7 ro 5 files]:

SharpCap Log: Log_2024-09-26T15_25_57-9292.log

3 x Screenshots of the issue as seen in FITs Liberator:
Screenshot-2024-09-26-195825.jpg [top ~60% lighter]
Screenshot-2024-09-26-200028.jpg [Top ~20% lighter]
Screenshot-2024-09-26-200303.jpg [100% perfect]

1 x Camera Settings Text File:
2024-09-26T15_36_31_USB3_Latest_SharpCap_Test_01_00003_Lum.CameraSettings.txt

Thank you, Robin, for the tip about the Turbo USB Setting, I will try that in the next imaging session, then update this post.

[admin]

Hi,

thanks for re-posting the attachments. There is nothing much to go on in the log, but the camerasettings file reveals that the ZWO Turbo USB was auto-set to maximum (100) by the ZWO SDK and the images look very much like images where the USB data transfer has glitched part way through the frame (if you have a colour sensor camera then often the colours change at the same point in the frame). I would definitely give the minimum value for TurboUSB a go to see if it resolves the issue. It's also worth keeping the USB cabling to a minimum when testing this sort of thing - take any extensions/hubs out while testing and only re-add if you have a stably working configuration with the original USB3 cable .

cheers,

Robin

[TimAldworth]

Thank you Robin for responding to my query, last night I set the Turbo USB manually to '60'. This reduced the number of frames affected by the 'blocking' to around 5%, which I can live with. I will reduce the value to minimum in my next session.

One thing I noticed though, using the SC Sequence camera command 'Set <Control Name> to <Control Value>' to set the 'Turbo USB' to a value, eg '50', within the sequence does not actually change the value as displayed, when using the 'Test Step' function. The 'Turbo USB value remains as set by the loaded camera profile ['100' in my case]. Using the same command to set the gain value in a similar manner works as expected.

A remaining affected frame screenshot [APP] attached [Pacman Oiii] for information.

[admin]

Hi Tim,

good to know that it looks like the Turbo USB is going to give you a fix (or an almost complete fix).

I suspect that the issue with setting from the sequencer is that the control is initially on 'Auto', so setting a manual value has no effect. Thinking about it, that sequencer step should probably set the control to manual if necessary before setting the value - I will make that change to the code.

cheers,

Robin

[TimAldworth]

Agree with the 'Auto' Control Robin, the sequence step will only set the required control value if 'Auto' is False. Probably affects other controls in a similar way, eg 'Gain' as well as 'Turbo USB'.
Thank you
Tim Aldworth

[TimAldworth]

Re-occurence of the original 'Blocking' issue on lights with Dark Cal and Flat Cal files used in preprocessing, when using the Sequencer.
Getting around 60-70% good frames from a sequence run. I now have the 'Turbo USB' set to the minimum value of '40'.
I am now putting the capture steps into a loop of n iterations with a 2 second delay, where it used to be a 'Capture n frames' step.
Hopefully this will increase the yield of good calibrated light frames.

[TimAldworth]

Update: The looping of single capture with 2 second delay, looped x100 had only a marginal effect on the yield of good light frames. Now around 70-80% good frames. I guess I will have to perform the 'Dark' calibration in post processing, after capture [Flats appear to pre process correctly].

[admin]

Hi Tim,

just to go over this again, does the effect vanish completely when you capture without setting SharpCap up to do dark correction or flat correction in pre-processing?

If it is only present with preprocessing enabled then there are really two things I can think of...

1) The extra CPU load of the preprocessing going on is affecting the data transfer of the next frame from the camera - I've never actually seen anything like that happen, but you could imagine it might be possible on a low power PC where the PC is struggling to keep up with the work needed

2) The preprocessing steps are being applied incorrectly (partially) by SharpCap. This would be more viable as an explanation if the frames all had the split in the same place, but with the split being in different places, it would be an odd explanation without there being a hardware error going on in the CPU/Memory somewhere leading to unexpected behaviour.

cheers,

Robin