Unfortunately, that is not possible. If you stack bayered images , the red pixel will fell over blue ones and green ones etc. Debayer is only possible before stacking. It will increase the load but it's to only possible way. so to get colour images, you have to checkmark the option "convert OSC images to colour. The Debayer option F8 only works for a single image.
Hah! I should've thought about that - Calibrate & Debayer, *then* Align & Stack. It's been a long times since I've done OSC so I'll give myself a pass for goofing that one up. The result is certainly interesting though.
In the case of the images I attached above, they are the same stack. The first is the non-debayered result. I had automatic "Covert OSC to color" disabled. To get the color image I waited until the stack was complete then I simply debayered it (F8). These shapes appear in most and possibly all of the stacks I ran last night.
Testing out on OSX, Kstars 3.3.7.
I am able to get ASTAP to run, however I have not been able to get a solution reliably. Sometimes trying a second or third time immediately will result in success. Saving the images from the alignment tab that failed and loading them in to ASTAP by hand proves that it can get a solution with the images as they are. I'm not sure but I think maybe the failure appears to be related to the Field Height Image setting in the alignment tab of ASTAP, which I notice is sometimes erroneously set at a number less than 2x the actual. I haven't figured out how this value is getting in the config. I tried forcing this setting in Ekos (presumably with the -fov parameter) but it is overwritten each time and doesn't seem to take. I also noticed that the command line parameters for the astrometry.net solver pop into the options field if you click on the pencil icon to open settings then select OK. This is reproducible.
Just released a new macOS version (0.9.298). It would be nice if you could test it. My testing of the macOS version is very limited. I compile it using virtual machine running 640x480 resolution only on a old laptop.
I have it running presently. I'm working with OSC tonight. Some feedback while running live stacking:
- The UI becomes quite slow to respond when live stacking is enabled.
- Dragging the image around is glitchy, especially when live stacking is enabled.
- When adding flats they don't appear in the list until after you press "analyse". Added flats do not have a checkbox next to them.
- I get odd patterns in the images from time to time. For example:
- The noise reduction appears to work quite well as evidenced by the smoothing of the background.
Overall very promising results. Keep up the good work!
I'm testing live stacking on OSX. I see the OSX build is listed as being a version or two behind the others. Is it possible to get an OSX build? I'd like to provide feedback on the latest and greatest so I'm not reporting things that are already resolved.
Tested it out a couple of nights this week. I admit I forgot I had it configured. It "just worked".
And wow - very fast solutions. Love it. Nice work Jasem & Hans.
I tried to build on my new laptop running Mint 19.1 using the details in this post:
Results were the same as alacant:
[ 96%] Linking CXX executable kstars /usr/bin/ld: cannot find -lsecret-1 collect2: error: ld returned 1 exit status kstars/CMakeFiles/kstars.dir/build.make:224: recipe for target 'kstars/kstars' failed make: *** [kstars/kstars] Error 1 CMakeFiles/Makefile2:393: recipe for target 'kstars/CMakeFiles/kstars.dir/all' failed make: *** [kstars/CMakeFiles/kstars.dir/all] Error 2 Makefile:140: recipe for target 'all' failed make: *** [all] Error 2
Confirmed this *did* solve the problem for me:
knro wrote: <code>
sudo apt-get -y install qt5keychain-dev libsecret-1-dev
Please accept my humble apologies. I did not intend criticism or disrespect with the statement.
sterne-jaeger wrote:Seems like nobody needs such a dialog - myself included.
It would be frustrating to wake up to a dialog asking if I want to flip and find that the system sat waiting for input and stopped imaging.
... However, it may make it unclear from a planning point if or when the flip may occur if it is no longer associated with one (or both) of these tabs. It will also make it easy to forget to consider it as part of the imaging sequence if it becomes otherwise "hidden" by relocating it away from these tabs.
The design idea is slightly different. The meridian flip behaviour is simply an attribute of the mount and not of a capture or schedule sequence. As long as you do not change the meridian flip behaviour, it remains the same for all your captures and schedules. I do not see a reason turning this behaviour on and off for specific sequences.
Yepp, this remains unchanged. The Mount module requests a meridian flip permission from the Capture module. As soon as a frame capture is completed, the Capture module grants the permission and waits, until the flip is completed. As soon as it is completed, it re-aligns and restarts guiding. By the way, this behaviour remains untouched.
I think the flip *during imaging* should be well coordinated with the imaging sequence, and highly visible within the sequence, and predictable.
Got it. Thank you for the clarification.
If the mount tracking can be disabled that would be ideal.
I wonder if it would be best to handle these details in the driver's though as a set of limits that fall within the mount's capability. These would be exclusive of any flip function requested by Ekos.
ChrisRowland wrote: I woud be wary of adding more complexity to something that is already causing support problems becuse of it's complexity.
Doing the pier flip early will probably need further information from the mount and also a bool SetSideOfPier(PierSide ps); function. The driver would need to implement this, including reporting an error if it can't be done. Many mounts can't flip early so some way of notifying the user that it's possible would be needed. Some indication of an allowable hour angle range would be one way.
A fair point. I admit I am unfamiliar with out Ekos presently initiates a flip. I suspect it may just be a normal slew command?
In the case of my equipment (paramount), TSX mostly controls when the early (or late) flip is available I. Generally, I keep the flip point as far east of the meridian as possible. As long as the mount has passed that line, issuing a slew is enough to get the job done. In a case like this it could be as simple as re-issuing a slew command and trusting that the mount knows what to do.
I guess a complexity in this is ensuring that Ekos knows to reset guiding and the model due to the flip. In that case it would need to know the change in the side of the pier.
I agree with Jasem and Wouter. An unattended meridian flip that is coordinated with my imaging strategy is a required feature for me. A merdian flip is a "major" action in an imaging sequence, much as guiding, focusing, capturing are. It would be frustrating to wake up to a dialog asking if I want to flip and find that the system sat waiting for input and stopped imaging.
As an imager, I primarily interact with the capture and scheduler tabs. I can agree that maybe the flip feature might be better located elsewhere (like in the scheduler). However, it may make it unclear from a planning point if or when the flip may occur if it is no longer associated with one (or both) of these tabs. It will also make it easy to forget to consider it as part of the imaging sequence if it becomes otherwise "hidden" by relocating it away from these tabs. I think the flip *during imaging* should be well coordinated with the imaging sequence, and highly visible within the sequence, and predictable.
I think having it in the mount tab as an option to flip exclusive of any imaging might be handy for some or at least as an optional safety to keep a mount from a pier crash if it is incapable of saving itself from that kind of doom. Maybe use it as a means of overriding whatever default behavior the mount itself might do (some mounts will autoflip on their own or just stop).
However, it would be handy to override even those basic functions within some part of the imaging sequence control, whether in the capture module or (even better IMHO) the scheduler. I say this because it moves the control to a single point - where you're controlling your imaging.
I suppose it's possible to have the switch in 3 locations (mount, capture, scheduler) and have an order of priority such as scheduler overrides capture overrides mount setting for the flip.
Also nice would be to be able to set both positive and negative HA values for when the flip happens for mounts that can flip well outside of the meridian. Right now it seems it only accepts positive values.
Happened to me to.... Don't think I turned it on as I didn't know it was there in the mount module.
Maybe the best approach in the mount module would be to default to whatever the mount's controller wants to do (default in Ekos: no action). Then call the option in the mount module a type of slew limit or override to the mount's own behavior.
I've run into similar problems with inconsistent measures. I sought to solve for variability by increasing the number of frames but this didn't seem to help. I tried pretty much all of the settings but didn't take a truly scientific analysis toward figuring out what worked best or why. Long story short, about the only thing I could find that behaved consistently was the inconsistent behaviour.
What really did help is using full-field mode which I resisted because Ekos doesn't seem to have the ability to use focus mode in cameras that support it. My hesitation was that it would be slow, and it is. However, by constraining it to 15%/50% I've found that I do generally get much more consistent behavior and HFR results far better than I'd seen in the past. Plus, it usually gets to best focus in 4-6 iterations where using subframes sometimes took 15-20 and multiple restarts. I'm guessing but I think full frame works better due to the averaging of HFR of the stars which has a stabilizing effect for the algorithms. I now let the focus module determine when I need focus, and for the most part things "just work". On occasion it does go wonky, and end up picking a focus that's far enough out that I can see the secondary mirror shadow. Fortunately this is rare and possibly related to bad seeing. I need to look into that at some point.
Details of my present config in case it's useful:
Optics: focal length 1700mm, f6.7
scale: 0.72 arcsec/pixel
step size: 2000 max travel: 5000 tolerance: 1%
Algorithm: polynomial Detection:gradient
Focus all filters w/ L as they're parfocal enough to get away with it.
No dark frames used, although this might help.