2 camera anytime soon? Any alternatives?


#21

Remember chaps I am not one of the SGP developers. I have no control over what Ken and Jared do.

All I can do is say what I think about this, and it’s my opinion that this is far more complex than you realise. For example if you are dithering you can’t be imaging or focusing in any acquisition chain. Dither will spoil an image and upset focusing.
qw
Expecting users to manage their imaging in a way that assumes that one imaging chain has some sort of priority will at best delegate synchronising problems to the user. It will generate unending support problems.

The shortcuts suggested to get started will prove to be unworkable.

The fact that no one has implemented a successful product with this should be a big clue that indicates that this is more difficult than you think.

I’m basing my opinion on over 30 years in software development for a scientific instrument manufacturer. This is exactly the sort of automation product that we would get requests for, that on the face of it looks easy to implement. I was on teams implementing some of them and the only reliable way was to keep them simple. If they weren’t then the work and complexity went through the roof. We had, by comparison, unlimited resources, teams of developers working full time, with separate documentation and marketing people.

I’m sorry to be so negative about this, but I think it’s better to be realistic about how I see what the prospects for this are.


#22

I appreciate the honesty and the level of difficulty that is involved with this. It’s still a great program and has alleviated a lot of headaches that caused me to leave the hobby in 2011. Love the mosaic end of the deal.
Hope there is a solution, but if it is not possible, I’m not going to jump out a window over it.


#23

I would generally agree. I really do like SGP much better than the old school systems like MaxIm that I had used since the mid 90’s and certainly do not plan on dumping it entirely. Having said that, if there is other SW, now or in the future, that allows good two camera function and SGP does not, I would use that instead of SGP for those situations. Just common sense, really.

I really think that the best solution might be to work with those user-coders that are interested in implementing this in an external software.

So I guess what the multi camera users like me really want to know at this point is what the plans are regarding two camera function:

  1. We have given up this idea - not ever gonna happen
  2. We may do it at some point but don’t hold your breath
  3. We will add functionality to allow external programs to manage this and plan to do this in the next (time frame)

Thanks


#24

A possible alternative:
I have described in detail in a couple of other threads my use of 2 and 3 scopes/cameras all operating independently with no dithering performed by the controlling SGP program. It is very efficient producing close to 200% effective imaging for a 2 camera setup. The only real lost images are the slave images being taken when a meridian flip occurs, or a target change occurs. This has worked wonderfully for me. Here is a way to introduce dithering:

Assume a single target imaging for 3 hours. Normally you would define 1 single target that would take all the images for the 3 hour session on each camera.

Instead, setup 6 targets, each target with appropriate start/stops times so they follow each other in order. All six targets of course use the same basic coordinates, only differing enough to produce the desired dither. Each target would need to Slew and Center, but after the first would be fairly fast. The slave targets would include an initial delay to guarantee they started their first image after the Master finished the Slew/Center.

Not particularly elegant, and definitely a nuisance to program, but should work.


#25

I have indeed thought about that as a workaround but it just seemed a bit of a kludge so have not done it. If one could have some sort of input script to do that for a given object, it might be more practical, but that also would need changes to SGP, if I am not mistaken. Plus, to paraphrase “Jaws” - “We’re gonna need a bigger input box”.:wink:

One could similarly use start/stop times coordinated between instances to synch the two instances -
but that is equally kludgy.


#26

Hi @Chris,

Again I think your input is good and I don’t doubt the experiences you’ve had in your line of work - these are good reminders to stay focussed on what is important and not get sucked down the rabbit hole.

I do think though that maybe you underestimate the level of understanding that people might have, especially those who end up with a dual scope setup. Yes it won’t be for everyone but these synchronisation problems are already being dealt with in various ways and I think the general impact on dithering in a multi scope setup is well understood. Also there are applications which offer this, APT being the obvious one which implements a master/multi slave system quite well (although it has other shortcomings).

Taking everything into account I would say that I agree with you that a comprehensive implementation of multi scope imaging is going to be very complex, not cost effective and for those reasons won’t happen any time soon - if ever. I don’t agree with this though:

I don’t think anyone, with maybe the exception of the developers, would be in a position to make such a call yet. In any case why not leave it up to them?


#27

Genius! Could get messy with mosaics though :smile:


#28

Maybe on a surface it seems so, but not everyone is an active forum participant. If people don’t participate in a pool, it doesn’t mean they are not interested in this feature. It always like, somebody else is taking care of it, why should I bother? There are a sensible percentage of users who would greatly appreciate a second camera control feature. And they are ready to pay extra for that. Well, most likely they are, because if you can control properly a second camera, it means you can save money on a second computer and also be more proficient with your image acquisition and be at easy when you are doing so, which is very important for all of us. Anyway, it would be fantastic if our favourite SGPro developers decide to implement this feature!


#29

@mtau

Guilty as charged and i think you are right, there are quite a lot of people out there who would love this functionality and would be prepared to pay for it. I am not really a forum person but I do run a triple widefield rig using the three instances of SGP on different old laptops. I would definitely be in support of a multi function software and would view that development both as a benefit to me and others using multi systems, but also as an investment in that SGP would be leaps ahead of its competitors. Once you get to two, the “speed” of capture is mesmerising and I have little doubt that many more people would follow. I know nothing of programming so have to take everyone’s word for it that this is difficult to implement in a form that is flexible enough for all the different systems out there. I suspect that people like me who are trying to work with multi systems are finding their own ways but I would say that double or triple “speed” systems are real weather beaters and would strongly recommend them once you get your head around the cable complexity!

I used to use the software in Maxim 5 that CCDMan refers to, quite successfully actually, but the master/slave system that this used was linked to specific computers and in theory using non-licensed multiple instances of Maxim. Once M6 came out i abandoned that and have been SGP ever since after being persuaded to look.

I don’t do anything special with my captures. A very good imager always encouraged to go after as many frames as possible so I tend to go for just one object a night/multiple nights. I use an unguided mount which just makes life easier and i point the main central system at whatever target. The secondary systems either side are pointed very close, but not at exactly the same point, and i set similar runs in terms of timecand numbers of frames. This is often L or Ha in the central system and L or RGB on either side, or O and S, or H and H or whatever - flexibility is everything to me. Once the central system has plate solved i press run sequence in the other two systems (obviously no mount is connected on these) and walk away once the first frame is in on each computer. I don’t dither at the moment as I have found that when i combine eg L frames from different systems, the noise largely reduces to very acceptable levels. I accept that when there is a flip i will potentially lose the frame from either side system. Reality is that this is rare and by manually synchronsing the start times so they are all running focus prior to capture, the frames do tend to end more or less together. I haven’t really messed around with imposing delays etc and apart from maybe adding an extra frame in the secondary systems i rely on gut feel and occasionally calculations for timings.

Just my tuppence-worth. I’ll go back to my hole ;-). I don’t see this as clunky, just an acceptable and occasional loss of data which is more than made up for by doubling or tripling the “speed” of capture. Linking and coordinating everything together however would be great.


#30

Elaborating on my post above of using multiple targets of the same target with a slight offset on each one.
If you are imaging the same target over several nights, you can easily get an automatic dither by the simple fact that the center process is likely to be a random offset of several pixels each night. This assumes your system is not set up to insist on a 1 or 2 pixel accuracy for the center operation. By setting your requested accuracy to perhaps around 20, you should have a good random distribution. If you have imaged the target over 5 or 6 nights, you will automatically have a decent dither for the full collection of images.

For 1 or 2 nights of imaging, you could also accomplish this without the need for altering the individual target coordinates by interspersing a slew far enough away from the target to produce a random center on return. That target for the slew would not need to do a center, so would be very fast.


www.mainsequencesoftware.com