Humason New Observations, Questions, Updates

[rrskybox]

1. I'll have to look at it. Is there anything else running concurrently, e.g. Image Planner?
2. Easy -- never was a reason for a limitation.
3. Been a while since I've looked at Autoflip. It's somewhat complicated. There may be a reason why it's limited to Paramounts. I'll let you know.
4. Although nothing is ever perfect, there are some reasons why I chose the current file structure, mostly having to do with making it easier to automate the post-processing of images. As always, feel free to diverge -- that's one reason that I made the code public. Maybe there's a benefit that I don't recognize.
5. Attached is my shutdown script to play with. It's got a lot more than you're asking for, but it gives you the gist.

ShutDown.txt

[rrskybox]

Re Item 2: Done. I'll push an update sometime today. Re Item 3: For autoflip to work, a mount driver must return the current side of pier, and, TSX must pass it through. Obviously Paramounts do, but I couldn't tell you about any other mounts. Without knowing the current side of pier for a mount, it's almost impossible to reliably know when a target has crossed the meridian, given all the other things that might be going on. At least, it's been beyond me and lord knows I've tried.

[rrskybox]

I don't remember where this was brought up, but I've published the application that mentioned re assembling fits files for image processing. You had said you might want a peek.

[https://github.com/rrskybox/PreStack/tree/master]

[rrskybox]

Re Item 3: I got increasingly nervous about the comment on AutoFlip and using a Gemini mount. I had not considered what to do about a mount driver that didn't report Side of Pier correctly, or if at all. So... I added a checkbox in the Sessions tab to enable/disable an automatic meridian flip. It is adjacent the button where you can check to see if the mount driver is reporting Side of Pier correctly. Humason will not flip the mount if that is not enabled. Build 235.

[rrskybox]

Item 4: You pretty much have the changes that are required figured out. Just comment out all occurrences of "AutoSaveOn = 0" in imaging.cs. Then comment out any calls to ImageFileManager.SaveLightImage. That should do it... I think.

Item 5: Humason will launch any standalone executable (.exe, .vbs, etc) that you link to. It would be silly, but you could link to Notepad.exe and launch it if you wanted. Anything probably works as long as it's an executable. If you wanted to write something in Python then that's fine too -- just link to its compiled executable. The code I sent you is just the source that I compile into the executable that I use to close my observatory. Hope that makes sense.

[rrskybox]

1. Yes, you want to set AutoSave = 1 in Sequencer.cs Line 587, but also AutoSaveOn = 1 in Imaging.cs Line 329 and 455 (for autosaving Flats). I don't remember why I didn't use the AstroImage class for imaging and saving flats. I may go back and revisit that although I hate to mess with something seems to be working.

2. And then, yes, you want to comment out lines 72-73 and lines 122-123 in ImageFileManager -- or, you could comment out the 5 references to ImageFileManager methods in Sequencer.cs and Imaging.cs (which is the cleaner solution IMHO).

The remaining 5 "AutoSave=0" instructions are for turning off saving autoguider images while autoguiding. You could reverse those as well if you're interested in saving those images. Those places that I specifically set AutoSaveOn to 1 are places where I had to save the image for plate solving, calibration or optimization purposes -- there's no reason not to have TSX save them in the TSX directories as they are throwaways -- that's one benefit of saving the images that you want to keep externally to the Software Bisque directory -- you can delete those saved in the Camera Autosave folder en mass without worry -- primarily optimization, focus and CLS images.

[rrskybox]

I think running on diverging code bases is a recipe for disaster. So, although I still think this is a step backwards, I added a configuration option (in the Options window) to turn on TSX AutoSave. I also ended up refactoring some of the imaging code so I could have screwed something else up there. Build 235 should carry the changes once I finish testing it.

1. Still looking at it.
2. My first guess is that you've got hot pixels. You probably need to AutoDark or Full Reduction to get rid of them. Hot pixel removal is something built into @Focus3.
3. When you say "calibration numbers", are you referring to the autoguider set up (exposure, etc) or the autoguider calibration vectors? Need some more details here.
4. The "edge margin" is the minimum number of pixels that the guide star must be off from the edge. Try 32 or 64 for an edge margin. It doesn't need to be any wider than half your tracking box really. I'll look, but I'm not sure my search algorithm doesn't go bonkers with an edge margin greater than half the overall image width. I probably should throw out an exception error if that's tried.
5. Worth some discussion. I purposely leave the camera connected so it doesn't start warming up for two reasons. The first is that some older models like to have their temperature raised gracefully. The second is that I like to keep the temperature down in case flats are done manually after the session. That said, I really don't have strong feelings here. Thoughts?

[rrskybox]

1 -- This is yet another reason Humason was designed to do its own file saving. For file naming, TSX applies the "name" used in the last slew. TSX also enters that "name" in the FITS header for the OBJECT field. Humason uses RA/Dec coordinates, not target names for slewing. The target "name" that TSX uses for any slew using RA/Dec coordinates is "Star Chart Center". This is why that shows up in the TSX AutoSave file name (and its FITS header). The reason why Humason uses RA/Dec coordinates rather than catalog name is that 1) many of the non-stellar catalogs have inaccuracies, and 2) most of the time a user will adjust the position of their FOV at least slightly to best frame the target and/or center a star for autoguiding. So, if one wants to use TSX AutoSave, then you're pretty well stuck with its limitations. Note that this is all fixable, of course. But, by the time you've got that all sorted out then you've pretty much done what Humason already does -- just put it in a different directory. Frankly, I'm not aware of any other sequencer automation that uses TSX and doesn't utilize an independent file structure.

2 -- AG3 is a field focus algorithm. I'm pretty sure that the developer scrubbed out hot pixels in the process. Not so in AG2.

3 -- Omitted in code for some reason, hopefully not a good one. Fixed now.

5 -- Changed code to disconnect all devices at end of session, if a shut down script as not been configured.

Still testing the latest version.

[rrskybox]

Build 235 checked out and published. Will close this issue up at least for now.

[rrskybox]

I use AF2 exclusively, but with AutoDark enabled. It helps. I added an option in V235 that allows you to choose the focus reduction independently of the other imaging. That may be useful to you.

[rrskybox]

Issue #6. Hmm... The ADU number only sets a target to optimize a guide star exposure time. I think the question is why isn't Humason finding a guide star. If calibration is successful, then TSX must have been able to find one. The limitation of TSX's built in is that it will "find" stars that are too close to the edge or too close to other stars (or hot pixels). On the other hand, Humason's method gets confused if there are too many stars in the field. This is where using the Guide tab as a diagnostic can help.

1. Slew the scope to your target. (Set the Autoguide Reduction type to AutoDark if you can.)
2. Set the default guider exposure to 1 second.
3. Click on "Find Star". Monitor the TSX guider image produced. If there are no stars visible, then increase the initial exposure by a second. Try again.
4. When a star is "found", then check the coordinates on the autoguider image to see if it really is at the right place. If so, continue.
5. Click on "Optimize". A number of images will be taken with different exposures, attempting to adjust the light source to meet the ADU requirement. If it's too dim, then the method defaults to the maximum exposure time. If it's too bright, then the method halts at the minimum exposure time.
6. Click on "Calibrate". Let it run the its routine. Should work.
7. Click on "Autoguide" and check TSX graphs for reasonable guider action.

If everything works with these individual steps, then you are dialed in and ready to go for any session with this set up. This is the basic workflow that Humason runs through when operating, so if it breaks at any one of these steps you'll know where the problem is. Let me know.

Issue #7. Look to see if you have two filters scheduled for each loop. Might be the problem.

[rrskybox]

7 -- That makes sense. Changing the name won't automatically drop the filter. After setup, Humason manages filters by filter index for each imaging sequence, not by name. That's because that's how TSX does it. Not a good reason; just a reason.

8 -- I don't follow the DSLR posts much, but I seem to recall several recently on the TSX Pro forum that had something to do with something similar. One post is here. You might check that out. First, though, are you able get a good image just using TSX stand-alone (i.e. without Humason)? If so, we'll take a look to see what Humason might be doing differently and try to get that fixed.

[rrskybox]

Good deal. I think that might have been the gist of the forum post(s) as well. I' m going to close close this issue up. If you continue to have difficulties with autoguiding, just open a new comment and we'll get focused on that.