My Python scripts broke between 4.1.11137.0 and 4.1.12025.0

[lowenthalm]

So I have a several scripts that access various controls, such as binning and the focuser controls, etc. These all worked fine under version 4.1.11137.0 in late October 2023 (same windows 10 installation as I have now, but there have been a few security updates since then, I presume). I finally got some clear skies, but full of moon; a perfect time for testing the latest of SharpCap! I immediately ran into all sorts of problems with various controls objects not existing that my python scripts depended upon.For example:

new_position = ... my calcs, my calcs, my calcs ...
SharpCap.Focusers.SelectedFocuser.Move( new_position )

returned "Move" does not exist in the SelectedFocuser object. When I went into the console and used the auto-complete feature to browse down to the SelectedFocuser, Move was listed as a member, but showed a, empty call format in the documentation popup.

The next script I tried for a similar error:

cur_bin = SharpCap.SelectedCamera.Controls.Binning.Bin

returned the same sort of does not exist error in the Binning object. Just as with "Move" above, Bin was listed as an member of Binning, but the documentation popup was again blank.

Rather than rewriting all my code, I thought I had better ask you what might have changed to cause this first. Maybe I need to import something into my code to allow access to these objects, or maybe they have been deprecated. I didn't see anyone else posting problems about Python error scripts, so I am thinking I am not doing something quite properly. All these scripts worked last night using 4.1.11137.0 before updating to the latest SC version. I reverted back to 4.1.11137.0 and everything worked fine again.

[admin]

Hi,

sorry about this - I made some changes to the way that the scripting worked for this sort of thing because I found that internal things in the code were usable in scripting, which I hadn't intended.

Unfortunately there are two problems... Firstly people had already found and started using the internal things, so I have ended up breaking those scripts.

Secondly, the internal things are still visible in the auto-complete help

I will have to have a look at the second issue to see if I can resolve the problem to make the auto-complete only show the things that will actually work. For the Move and Bin functions, the intended ways to do this were

Move... set the Position instead, so

focuser.Move(100) becomes focuser.Position = 100

Bin... there is a BinFactor property that you should be able to use.

I will also re-add those to the next SharpCap update, so you can either wait for that update next week or edit your scripts.

cheers,

Robin

[lowenthalm]

I found the bin BinFactor when I started searching for a fix, but it seemed to be the pixel area of the bin, not the bin value. This looked like something for internal use and it also seemed pretty weird in my code to check if the bin was 2 by checking to see if BinFactor was 4. I thought maybe you were changing the code to handle differing X and Y bins, but the BinX and BinY likewise seemed inaccessible.

I found I could get the actual bin value by using Binning.Value, but had to explicitly cast this to an int to be able to properly do comparisons with integer values for bin in my dark and flat lookup tables (selection automation of these was the some the purpose of some of my scripts). This seemed weird to me as it appeared to be a string, so the comparison to an int should have worked. I was too tired to sort out the reason for this comparison behavior.

As for Move( ), I will try assigning directly to the position. I think I might have tried this originally and found it didn't work as well for some reason, but I will try again.

Are there any other dropped items in the controls I need to watch out for, or are the changes too numerous to enumerate? Do you expect to make further changes to the exposed members of these objects? I may need to rewrite my code so that I have my own API to the SharpCap API so its easier for me to globally correct my code when SC API changes occur. I had done this to some extent, but didn't bother when using object members that seemed to me not likely to change.

[admin]

Ah, yes, the BinFactor is the number of pixels that are being binned together, so for 2x2 binning, it is going to be 4, 3x3 will give 9 and so on. Some cameras also have the possibility for asymmetric bin like 2x3 or 3x4.

I have reinstated the Bin property and Move to make them usable by scripting in the next update and also managed to fix the autocomplete so that it will only suggest the things that are really accessible.

I suspect that overall I have removed dozens of methods/properties that were really meant for internal use but could be accessed previously by scripting - I can't easily make a list, and who knows if anyone was using those parts of the code via scripting. I'm happy to reintroduce things that have been removed on a case-by-case basis if it makes sense to have them usable from scripting.

cheers,

Robin

[Jean-Francois]

Hello Robin,

OK, thanks to mention it. I will test all my script as soon as you have upload the next update.

Regards,
Jean-Francois

[lowenthalm]

Thanks Robin! In some cases of accessing controls, the value works fine, but Bin is some sort of strange object that requires casting to make it useable. I was wondering whether there might be cameras with asymmetric binning that would make a single integer Bin value problematic, but I couldn't image what the use of such a feature would be!

As I said, I think I tried assigning the focuser position to the control value, but found Move worked better for some reason. Assigning the value directly seems the most obvious thing to try first, so I am pretty sure my memory on this is correct. Setting the focus position critical for some code I wrote that calculates the exact focus required based on temp and other telescope specific conditions so I can skip focus scans most of the time. Thanks for putting Move back in.

Its really tough to shake missing API objects out of interpreted script such as Python. I miss C++ compilers. It just wouldn't compile if an identifier in libraries was gone!

[Jean-Francois]

Hello Robin,

OK thanks to reinstalling the focuser Move() function.

I test several scripts with the focuser ... all my scripts are "broken".
The problem is ... I have several computers and several scripts.
It is not easy to update all the computer/script ... at the end one change will be missing.

Regards,
Jean-Francois

Note: I remark that last year with one of my script around 1 hour before the occultation of Betelgeuse.
One script (for the occultation capture) was not up to date ... so I started to debug the python script at the telescope in the night ... with a "tick-tack" clock countdown.

[lowenthalm]

It appears that the assignment:

SharpCap.Focusers.SelectedFocuser.Position = new_position

works as a replacement for Move( pos ). I believe I may have tried to assign to the focuser field .value, which maybe doesn't always work. Luckily, it turns out I had the use of Move localized to one function so the mod was fairly quick, but for people with move scattered across many scripts, it would be easier to make Move( pos ) public again.

Testing with the latest version of Sharpcap has been hit and miss. Some of my python dives into odd places such as controlling live stacking and also the SharpCap.Mounts.SelectedMount.GetSkyCoordConverter() coordinate transformation kit and these seem to be OK.
HOWEVER, I no longer have access to SharpCap.LiveStacking.ViewModel, where a bunch of the controls for LiveStacking can be found. I have code that auto-sets the FWHM filter in live stack. This code is now broken, as I haven't found another route to this data. So these are inaccessible, and I don't know how to get at equivalent data now:

SharpCap.LiveStacking.ViewModel ...

Used to auto-calculate the appropriate FWHM filter setting:
SharpCap.LiveStacking.ViewModel.FilterViewModel.MaxFWHM
SharpCap.LiveStacking.ViewModel.FilterViewModel.AvgFWHM
SharpCap.LiveStacking.ViewModel.FilterViewModel.MinFWHM
SharpCap.LiveStacking.ViewModel.FilterViewModel.MaximumFWHM

I also auto initialize the following now inaccessible controls so I always start with my standard live-stacikng setup:
SharpCap.LiveStacking.SaveRawFrames
SharpCap.LiveStacking.ViewModel.BrightnessFilterViewModel.BrightnessFilter
SharpCap.LiveStacking.ViewModel.FilterViewModel.FHWMFilter
SharpCap.LiveStacking.ViewModel.AlignmentViewModel.AlignActive
SharpCap.LiveStacking.ViewModel.GuidingViewModel.GuidingAndDither.Enabled
SharpCap.LiveStacking.ViewModel.GuidingViewModel.GuidingAndDither.AutoDither
SharpCap.LiveStacking.ViewModel.GuidingViewModel.GuidingAndDither.RequireGuiding
SharpCap.LiveStacking.Actions.DisableAutoSaveAndReset()
SharpCap.LiveStacking.SaveRawFrames = 0

[admin]

Hi,

thanks for the list of live stacking breakages. The LiveStackViewModel was not supposed to be available from scripting, so I won't be reintroducing direct access to that, but I will try to wire in equivalent properties via SharpCap.LiveStacking directly for you. Hopefully I will find some time to do that in the next week.

cheers,

Robin

[lowenthalm]

Thanks!

I have been scouring through my scripts, and found a few more missing objects I missed in my last post:

SharpCap.LiveStacking.SaveRawFrames = SharpCap.LiveStacking.SaveRawFrames.WhileNotPausedOrDithering
SharpCap.LiveStacking.SaveRawFrames = 0
and

SharpCap.LiveStacking.GetFilenameForSaveWithAnnotations()

that last of which I use to get the live stacking output directory path. Maybe there is someplace else I can get this data from?



I tried to go directly to the data in the FWHM history plot to dynamically adjust the FWHM filter, but coudln't figure it out well enough so had to settle for just using ViewModel.FilterViewModel.MaxFWHM, ViewModel.FilterViewModel.AvgFWHM and ViewModel.FilterViewModel.MinFWHM.

In addition to the editable/clickable controls, access to all the displayed statistics, such as stacked and dropped frames, etc, would be handy. I would be able to detect when dropped frames start rising and/or star counts start dropping during stacking to know when a problem is arising. I hadn't thought of this before... is there a way of access the accumulating stacklog from Python scripting before the stacklog is actually written to disk? This might already be present, and I just hadn't found it.