RE: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments
I'm not convinced that DirectShow (etc) addresses the same problem as the one Hristo is trying to solve. DirectShow is all about file formats, codecs, device control and rendering. Hristo's proposal is specifically not about doing that but focuses on the problem domain of astronomical observing and making video control easily accessible to the ASCOM app developer. I speak only for myself here, but I know very little about DirectShow or controlling video cameras but the proposed interface looks completely familiar to me. I feel that I could dive in right now and write an ASCOM observing app to use video devices, without having to worry about what camera device I will use or what file format it is going to save in.
Sometimes less is more. By providing only frame-by-frame viewing within his interface, Hristo wisely side-steps all of the rendering and codec problems that don’t really belong in an ASCOM driver. Video rendering is an application concern, just as image display from a CCD camera is an application concern (ICamera drivers don't provide any way to display an image at all). We have many perfectly good applications for video playback. The job of the ASCOM interface is not to do all these things, but first and foremost, to provide a standard, device independent abstract interface.
Internally, of course, a driver may well use DirectShow to get the job done; Applications may well use DirectShow to render the recordings - but in each case, that's an implementation decision and having the ASCOM interface provides a decoupling point so that we don’t have to directly tie ASCOM to DirectShow or any other rendering/encoding technology.
> -----Original Message-----
> From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-
> Talk@yahoogroups.com] On Behalf Of Ray Gralak
> Sent: 16 May 2012 23:13
> To: ASCOM-Talk@yahoogroups.com
> Subject: RE: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments
> Hi Tom,
> There is already a couple standard video diver interfaces (DirectDraw and
> Windows WDM).
> If the Mallincam had one of these standard drivers then it should work with
> all kinds of applications, including MaximDL.
> -Ray Gralak
> Author of Astro-Physics Command Center (APCC) Author of PEMPro:
> http://www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:
> http://www.gralak.com/apdriver Author of PulseGuide:
> http://www.pulseguide.com Author of Sigma:
> > -----Original Message-----
> > On Behalf Of tom@gemini- 1.com
> > Sent: Wednesday, May 16, 2012 10:08 AM
> > To: ASCOM-Talk@yahoogroups.com
> > Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for
> > Comments
> > Hi Douglas
> > We have been trying to get you to develop an Video driver for the
> Mallincam Video camera now for
> > many months. The video from these camera's have to be captured with a
> video capture device into
> > a PC. Most of the Video Capture devices are Direct Show compatible, but I
> think the problem is that
> > they do not same in a format that MaximDL can use to focus with. These
> camera's have both
> > RS170A and S-Video outputs. European models work in PAL. They are
> controlled with RS232 links.
> > The serial specifications are located on the Mallincam Users Group at
> > http://tech.groups.yahoo.com/group/mallincam/files/63V5 Camera serial
> > communication_A1 .pdf or I have put them also on my web site at
> > So in the short run, we were hoping that an ASCOM driver for Video
> > camera's might be a way to get MaximDL to work with these very fine
> > Video Cameras. Are you aware that there are more than 1000 of these in
> use in the field.
> > Also many uses of these camera's broadcast each day and night on a
> > netwrork called NightSkiesNetwork that can be seen at
> > Sincerely
> > Tom Hilton
> > On 5/16/2012 9:33 AM, Douglas B. George wrote:
> > On 2012-05-07 6:41 PM, Hristo Pavlov wrote:
> > >
> > >
> > > Hi Doug,
> > > Thanks for your comments.
> > > It is impossible to define a standard for something that is unknown
> (e.g. define
> > > more specific application for Action/SupportedAcounts) without
> knowing what they
> > > are going to be used for. Having said that I agree that having an
> > > based only on those two methods is very bad, but this is not the
> case here. If
> > > you have a usecase for video camera for astronomy that is not
> covered well with
> > > the proposed API and which can benefit from adding more specific
> > > methods/properties, please share this usecase with us.
> > I'm objecting on principle to defining a "not-a-standard". ICamera
> > ITelescope have evolved to incorporate new features as required. I
> > sympathize with the reasons why people want a back door, but in the
> long run it
> > causes more trouble than it solves, IMHO.
> > > In your comment you are saying that free running video will be very
> useful. Can
> > > you elaborate more on how is this going to be more useful than
> supporting say 5
> > > frames per second with an image-by-image requesting mechanism
> as fast as the
> > > client application needs?
> > All I can say is our customers seem to want live video, probably
> because it
> > helps centering target, getting initial focus, etc. Perhaps five frames
> > second is sufficient.
> > > I am not sure I understand the question about DirectShow and
> Media Foundation.
> > > Can you be more specific here please?
> > How is this interface superior to existing industry-standard
> interfaces? What
> > does it bring to the table that is unique/better?
> > Doug
> > --
> > Doug George
> > Diffraction Limited
> > Makers of Cyanogen Imaging Products
> > 100 Craig Henry Dr., Suite 202
> > Ottawa, Ontario,
> > Canada, K2G 5W3
> > Phone: (613) 225-2732
> > Fax: (613) 225-9688
> For more information see http://ASCOM-Standards.org/.
> To unsubscribe from this group, send an email FROM THE ACCOUNT YOU
> USED TO SUBSCRIBE(!) to:
> Yahoo! Groups Links
> <*> To visit your group on the web, go to:
> <*> Your email settings:
> Individual Email | Traditional
> <*> To change settings online go to:
> (Yahoo! ID required)
> <*> To change settings via email:
> <*> To unsubscribe from this group, send an email to:
> <*> Your use of Yahoo! Groups is subject to:
Tom, to add to Hristo’s reply, people often get excited about the features of a particular device when discussing ASCOM interfaces. “But if it is designed like that, my XXX device won’t be able to use its ZZZ feature”. It would be a mistake to let an interface design be driven by the capabilities of any one device. In truth, you WILL be able to use the features of your device, but that will be a part of your specific driver and not necessarily part of the interface. Often, with a bit of imagination, a device’s bells and whistles can be used to great effect within its specific driver, without having to include those features in the interface design.
It is a difficult line between including enough features to be useful while keeping the interface device agnostic and lightweight. What is important is that the interface must be usable by any application _without knowledge of what device is actually connected_. In some cases, this means that some features of some devices will not be represented in the interface, this is especially true for devices with many features. This is a necessary part of the ASCOM philosophy, but it doesn’t mean you can’t use those features.
ASCOM has the specific goal of making it possible for applications to treat all devices the same (or as similarly as reasonably possible). Sometimes that goal is at odds with users who want to use all the bells and whistles of their kit interactively. Sometimes, an ASCOM driver isn’t the solution to your problem. If you need a highly specific application, then perhaps what you need is an app dedicated to your particular device. Again, this is a judgement call but most device vendors end up providing some sort of control application. A smart driver writer would produce a driver that can expose the generic ASCOM interface while also exposing a more device-specific API that app developers can talk to directly if they need more fine-grained control. The ASCOM architecture is very flexible and with a bit of imagination it is possible to come up with very full-featured solutions, the Gemini telescope driver is a great example of that.
I believe that Hristo is taking a balanced approach, he has a clear set of goals in mind, he has correctly understood the purpose of ASCOM, he has designed a well-considered interface and is being steadfast in resisting ‘creeping featurism’, but he is not closed to amendments where they are clearly justified. Please bear in mind that the justification “because my device has that feature” is insufficient justification for adding that feature to an ASCOM interface definition. An interface must represent all possible devices in a very general way. The balance to be struck is between keeping the interface generic and lightweight vs. including enough functionality to make the interface useful to observing applications. This compromise usually results in the inclusion of a number of Can* properties, but the further down that route one goes, the harder it becomes for an application to be developed to actually use the interface – the presumption must always be in favour of easy app development. In my view, it is better to start small, produce a few ‘real world’ implementations, discover what is actually needed based on the experience gained and then expand as needed. This design cycle is probably best done at least once before an interface is formally adopted.
I have no axe to grind here, because I don’t use video in my observing, I will not be writing any of the software and I have no vested interest in any application or technology, so in a sense the outcome has no bearing on me. But I do care about ASCOM and I know something about software engineering, so I offer the above opinions from a neutral architectural perspective.