Loading ...
Sorry, an error occurred while loading the content.

Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments

Expand Messages
  • Hristo Pavlov
    Hi Tom,   ... This is interesting and this is not how other intergating cameras I have seen work. The gamma for example only takes effect on the next
    Message 1 of 85 , May 19, 2012
    View Source
    • 0 Attachment
      Hi Tom,
       
      > So if the only video we can see, is after integration, we would not be able to
      > see the changes as we make them.
      This is interesting and this is not how other intergating cameras I have seen work. The gamma for example only takes effect on the next integration period. I am not 100% certain about the gain.
       
      Regardless of this I think there is still no need to make all frames available. Lets assume that your cammera allows you to see the gamma and gain changes immediately. Still an image pull mechanims will allow you to see those changes immediately as well i.e. as soon as you request the next image.
       
      The bottom line is I don't think this use case requires all frames to be made available to the client application. Do you agree with this or can you give me a better reason why you may want all frames?
       
      Regards,
      Hristo Pavlov
      Sydney, Australia

       
      From: "tom@..." <tom@...>
      To: ASCOM-Talk@yahoogroups.com
      Sent: Saturday, May 19, 2012 2:50 PM
      Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments

       
      Hi Hristo Pavlo
      Here is one answer from the Mallincam group provided by Andy Glasso

      "That's right, the camera displays a static buffered image during
      the integration cycle--whatever the camera was showing when the integration
      starts, typically the image from the prior integration cycle.

      However, you can make certain adjustments to the displayed image during the
      integration: Gamma, APC, and White Balance (not to mention settings on the
      frame grabber device). So if these settings are being changed by the user
      the image is not really static."

      So if the only video we can see, is after integration, we would not be able to
      see the changes as we make them.

      Tom Hilton


      On 5/18/2012 7:13 PM, tom@... wrote:
       
      I don't know how to answer your question as I am a very new Mallincam user.  So I have copied your questions over to the Mallincam users group.  I will try and repost there answers back to you.

      Tom Hilton

      On 5/18/2012 4:12 PM, Hristo Pavlov wrote:
       
      Hi Tom Hilton,
       
      The currently proposed draft is heavily influenced by what I know people are using video cameras for. I will be happy to learn more about other use cases and discuss how we can addapt the interface to support those usecases. This is why I am talking to this group.
       
      So Tom you are saying that Mallincam users want realtime video on the screen? Correct me if I am wrong but to be able to see interesting objects with integrating video camera such as Mallincam, you need to use an exposure of couple of seconds. This means that the image only changes once every few seconds. Because it is designed to be watched on a TV (for historical and other reasons I suppose) the same image is sent 30 times per second for the duration of the exposure - say 3 seconds. Then how is my proposed interface not going to work for you guys? You only need to refresh the screen only once per integration time and because ASCOM is about computers and computers screens you don't need to stay coupled with analogue 30fps video to be able to display images that only change once a few seconds. Isn't that correct?
       
      If you want to primirely use the driver to control the camera but want to display the output on a TV screen, you can still do that. The proposed standard will give you sufficient power to adjust the camera settings and see the effects (on the compiter), and then your camera output signal can be split in 2, one part going in the frame grabber and the other one going on a TV screen.
       
      If you want to broadcast the video on internet, then you certainly don't want 30fps but only need to chnage the image quick enough to see changes and slow enough to allow reasonable download over internet. Again this sounds to me as one image per second is probably good enough.
       
      Please explain if what I am saying is not correct and please tell me specifically what more you need for the Mallincam users?
       
      Regards,
      Hristo Pavlov
      Sydney, Australia

      From: "tom@..." <tom@...>
      To: ASCOM-Talk@yahoogroups.com
      Sent: Saturday, May 19, 2012 2:39 AM
      Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments

       
      Then Hristo Pavlov
      If we cannot use the driver to watch the video from the camera in real time, it really would not benefit the Mallincam users.  That is what 99% of them do.
      Yes they also need to be able to capture frames to present to programs like MaximDL so that they can autofocus, but recording video for later use is not what
      most user of the Mallincam do.  I would go so far as to say the most of the users of Mallincam clones (very bad clones at that) like the Orion video camera do the same.  It is sounding more and more like your proposal is specific to your need, which really leaves out real time video viewing and control of that camera during that process.  Am I totally misunderstanding you  when you say "The purpose of the proposal is NOT to give direct access to a video stream to a client. It is to allow a client to record a video file, not to display it on the screen or do anything with it. There are a number of benefits in doing it this way. "

      I don't think you are understanding what most of the people that use video camera's with there telescopes use them for.  They replace lens, and viewing thrrough these lens.  Viewing through lens, you only see black and white, as the eye cannot distinguish the colors.  It also benefits, people with very bad vision that cannot even see through a lens.    Please go onto http://www.nightskiesnetwork.com/ just one night to see what I am talking about.

      Sincerely
      Tom Hilton

      On 5/18/2012 6:54 AM, Hristo Pavlov wrote:
       
      Hi Paul,
       
      Sorry for calling you Chris :)
       
      The purpose of the proposal is NOT to give direct access to a video stream to a client. It is to allow a client to record a video file, not to display it on the screen or do anything with it. There are a number of benefits in doing it this way.
       
      Firstly video is very complicated matter, there are many formats and codecs. If the video stream is given to the end client then it will be up to the end client to record the video. This causes some performance issues but more importantly it puts a burden on every client software to use the ASCOM standard to deal with this matter (recording the video). This is not ideal and in fact very error prone. It doesn't add any value - really bad idea.
       
      A better idea is to leave it to the driver to take care of recording the video. I don't know how many videos you have recorded and reduced but you probably know that this is a heavy process that canot be really done on the fly. This is why we record video - because it gives us ability to play it back as many times as we want at out leasure so we can measure whatever we want to measure or extract whatever information we need.
       
      > There are other operations that involve multiple frames *in real-time* that will be prevented by implementing the interface as proposed.
      Paul, I am very curious for you to give me specific examples for those "other operations" as well as exactly how the propsed interface prevents them? I personally don't see any such operations that need all frames of a life video and cannot work with the proposed latest-frame mechanism that will probably be as good as 5fps or may be much better but certainly will not gurantee getting every single frame. Of course I may be missing something. Please give examples, okay?
       
      Lastly even if you have some very smart and custom operation that is so time critical and needs every single frame, it will probably be much better if you make this operation part of the driver and expose it as SupportedAction.
       
      Paul, I am happy to hear any suggestions and criticism you may have but please be *specific* and give examples.
       
      Thanks again for your time!
       
      Regards,
      Hristo Pavlov
      Sydney, Australia
       
      From: paulkccd <yh@...>
      To: ASCOM-Talk@yahoogroups.com
      Sent: Friday, May 18, 2012 11:26 PM
      Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments

       
      Hi Hristo,

      I think this was a reply to my post, not Chris' (I am Paul :-)

      I understand the purpose of the proposal, and agree that the goal of the driver is not to playback video. That wasn't the intent. There are other operations that involve multiple frames *in real-time* that will be prevented by implementing the interface as proposed.

      I think of a video stream as an image, but in three dimensions, X, Y, and t. Your proposal gives preference to X and Y, leaving the t coordinate to chance. This would be similar to giving access to only the latest downloaded row in the image buffer using the ICamera2 interface.. Perhaps that's easy to implement, but it does introduce problems for any software trying to process sequential rows in real time.

      Regards,

      -Paul

      --- In ASCOM-Talk@yahoogroups.com, Hristo Pavlov <hristo_dpavlov@...> wrote:
      >
      > Hi Chris,
      >  
      > The purpose of the driver and the proposed ASCOM standard is *not* to playback a recorded video. This is something that the reduction software will do and widely depends on the file format etc. Similarly the purpose of the ICameraV2 standard and drivers is not to display or process a FITS file, it is to make it possible to record such a file. So this means that the purpose of the proposed ASCOM IVideoCamera standard is simply to allow people to record an astronomical video file.
      >  
      > Because of this my view is that what you are suggesting as processing frames in an enumerable way doesn't have a role to play in the ASCOM driver for video camera. If the user wants to tweak settings and see how they worked, the individual frame request mechanism will do the job with minimal troubles.
      >  
      > However if you need to do something special with the video frames i.e. some kind of pre-processing before you save them in the file, then you need to create a video recorder that does this. For example ADVS (http://www.astrodigitalvideo.com.au/) is such a video recorder. Now the ASCOM driver is about controlling the video recorder not the camera directly. This falls in the 4-th usecase where the IVideoCamera controls a video recording system (that may use any camera including CCD).
      >  
      > Here is again a list of the considered use cases:
      >  
      > 1) Connecting to a frame grabber that receives analogue video signal from external video device that is generally unknown to the ASCOM client.
      >  
      > 2) Receiving analogue video data from a frame grabber but also controlling the camera that provides the video data to the frame grabber. In this case the driver (user) will be able to control camera settings such as gain, gamma, exposure, etc.
      > 3) Controlling a digital video camera directly. The driver will be able to modify the camera setting and will receive video back without a need of a frame grabber
      >
      > 4) Controlling a "video system" that is a complex device which has its own logic how to record a video and may allow the user to modify camera settings via the interface.
      >
      > In all cases the video is recorded by the *driver* not by the client that is using the ASCOM interface. The ASCOM interface is only for controlling the video recording process and possibly camera settings.
      >  
      > Regards,
      > Hristo Pavlov
      > Sydney, Australia
      >
      > ________________________________
      > From: paulkccd <yh@...>
      > To: ASCOM-Talk@yahoogroups.com
      > Sent: Friday, May 18, 2012 11:36 AM
      > Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments
      >
      >
      >
      >  
      >
      > Hi Hristo,
      >
      > I realize this may not be possible in all cases. One simple use case might be to process frames, stack/combine them, or to perform object/event detection in real time. Whether the driver chooses to do this by simply reading the video file or by keeping an in-memory buffer is up to the driver. If an in-memory buffer is used, perhaps the driver can limit how many frames are accessible at any given time.
      >
      > I can also imagine that a driver can provide a simulated video feed by using an existing video file instead of capturing it from a video device. The frame enumerator would then be a very simple way to provide access to the whole frame sequence for analysis and processing.
      >
      > Regards,
      >
      > -Paul
      >
      > --- In ASCOM-Talk@yahoogroups.com, Hristo Pavlov <hristo_dpavlov@> wrote:
      > >
      > > Hi Paul,
      > >  
      > > Thanks for your thoughts.
      > >  
      > > I am not sure what you suggest to be enumerable? The frames in the recorded file or all video frames generated by the camera as it runs (without recording). If it is the latter then in order to "keep" those frames for access by the client they will need to be stored somewhere. Some cameras can generate easily 1Gb of data for a 30 sec or less so it may not be a good idea to keep those frames for enumeration. This is also the reason behind my proposal only the latest frame to be available to the client for "review".
      > >  
      > > Having said all this I would like to know more about the usecase you have in mind for using frame access via enumeration? Why would you want to do something like this?
      > >  
      > > Thanks again,
      > >  
      > > Hristo Pavlov,
      > > Sydney, Australia
      > >
      > >
      > > ________________________________
      > > From: paulkccd <yh@>
      > > To: ASCOM-Talk@yahoogroups.com
      > > Sent: Thursday, May 17, 2012 11:05 PM
      > > Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments
      > >
      > >
      > >
      > >  
      > >
      > > I like Hristo's proposal, and see a value in providing a simple interface to control a video camera through a familiar ASCOM interface.
      > >
      > > One suggestion I have is to allow image frame access through an enumerator. The proposal provides access to the latest image, but to make it much more complete, the standard should also provide for access to all the frames captured so far. This can be done through a first/last/current/next/previous enumerator, for example.
      > >
      > > If this is too complicated to implement in general, then maybe it can be exposed along with a 'CanEnumerateVideo' property.
      > >
      > > Regards,
      > >
      > > -Paul
      > >
      > > --- In ASCOM-Talk@yahoogroups.com, "Tim Long" <Tim@> wrote:
      > > >
      > > > 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.
      > > >
      > > >
      > > >
      > > > Regards,
      > > >
      > > > Tim Long
      > > >
      > > >
      > > >
      > > >
      > > >
      > > > > -----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 <http://www.ccdware.com> Author of Astro-Physics V2 ASCOM Driver:
      > > >
      > > > > http://www.gralak.com/apdriver <http://www.gralak.com/apdriver> Author of PulseGuide:
      > > >
      > > > > http://www.pulseguide.com <http://www.pulseguide.com> Author of Sigma:
      > > >
      > > > > http://www.gralak.com/sigma <http://www.gralak.com/sigma>
      > > >
      > > > >
      > > >
      > > > >
      > > >
      > > > > > -----Original Message-----
      > > >
      > > > > > From: ASCOM-Talk@yahoogroups.com <mailto:ASCOM-Talk@yahoogroups.com> [mailto:ASCOM- <mailto:[mailto:ASCOM-Talk@yahoogroups.com]>
      > > >
      > > > > Talk@yahoogroups.com] <mailto:[mailto:ASCOM-Talk@yahoogroups.com]>
      > > >
      > > > > > On Behalf Of tom@gemini- 1.com
      > > >
      > > > > > Sent: Wednesday, May 16, 2012 10:08 AM
      > > >
      > > > > > To: ASCOM-Talk@yahoogroups.com <mailto: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 <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
      > > >
      > > > > > http://www.gemini- <http://www.gemini-2.com/downloads/63V5_Camera_serial_communication_A1>
      > > >
      > > > > 2.com/downloads/63V5_Camera_serial_communication_A1 <http://www.gemini-2.com/downloads/63V5_Camera_serial_communication_A1> .
      > > >
      > > > > > pdf
      > > >
      > > > > >
      > > >
      > > > > > 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
      > > >
      > > > > > http://www.nightskiesnetwork.com/ <http://www.nightskiesnetwork.com/>
      > > >
      > > > > >
      > > >
      > > > > >
      > > >
      > > > > > 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
      > > >
      > > > > interface
      > > >
      > > > > > > 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
      > > >
      > > > > and
      > > >
      > > > > > ITelescope have evolved to incorporate new features as required. I
      > > >
      > > > > can
      > > >
      > > > > > 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
      > > >
      > > > > per
      > > >
      > > > > > 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
      > > >
      > > > > > dgeorge@ <mailto:dgeorge@> <mailto:dgeorge%40cyanogen.com <mailto:dgeorge%40cyanogen.com> >
      > > >
      > > > > >
      > > >
      > > > > > Diffraction Limited
      > > >
      > > > > > Makers of Cyanogen Imaging Products
      > > >
      > > > > > http://www.cyanogen.com/ <http://www.cyanogen.com/>
      > > >
      > > > > >
      > > >
      > > > > > 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/ <http://ASCOM-Standards.org/> .
      > > >
      > > > >
      > > >
      > > > > To unsubscribe from this group, send an email FROM THE ACCOUNT YOU
      > > >
      > > > > USED TO SUBSCRIBE(!) to:
      > > >
      > > > > ASCOM-Talk-unsubscribe@yahoogroups.com <mailto:ASCOM-Talk-unsubscribe@yahoogroups.com>
      > > >
      > > > >
      > > >
      > > > > Yahoo! Groups Links
      > > >
      > > > >
      > > >
      > > > > http://groups.yahoo.com/group/ASCOM-Talk/ <http://groups.yahoo.com/group/ASCOM-Talk/>
      > > >
      > > > >
      > > >
      > > > > Individual Email | Traditional
      > > >
      > > > >
      > > >
      > > > > http://groups.yahoo.com/group/ASCOM-Talk/join <http://groups.yahoo.com/group/ASCOM-Talk/join>
      > > >
      > > > > (Yahoo! ID required)
      > > >
      > > > >
      > > >
      > > > > ASCOM-Talk-digest@yahoogroups.com <mailto:ASCOM-Talk-digest@yahoogroups.com>
      > > >
      > > > > ASCOM-Talk-fullfeatured@yahoogroups.com <mailto:ASCOM-Talk-fullfeatured@yahoogroups.com>
      > > >
      > > > >
      > > >
      > > > > ASCOM-Talk-unsubscribe@yahoogroups.com <mailto:ASCOM-Talk-unsubscribe@yahoogroups.com>
      > > >
      > > > >
      > > >
      > > > > http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/>
      > > >
      > > >
      > > >
      > > >
      > > > --
      > > > ExchangeDefender Message Security: Click below to verify authenticity
      > > > http://www.exchangedefender.com/verify.asp?id=q4H6GJoC031706&from=tim@
      > > > Complete email hygiene and business continuity solution available from http://www.tigranetworks.co.uk
      > > >
      > >
      >










    • Tim Long
      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
      Message 85 of 85 , May 21, 2012
      View Source
      • 0 Attachment

        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.

                                                                                                                                                                                                                                                

        Regards,                                                                                                                                                                

        Tim Long

         

        From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of tom@...
        Sent: 20 May 2012 19:32
        To: ASCOM-Talk@yahoogroups.com
        Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments

         



        Hristo
        I wish you would either borrow a Mallincam, of find someone close to you that has one, and go observe with them before defining specifications that will effect all Mallincam users.  We are all different, and each and every one of us use our Mallincams for different purposes.  I know you joined the Mallincam group.  While over there why not ask if anyone lives close to you.  Seeing is be-leaving,   I really wish you could see one or two in action.  I know you are trying to help but I am beginning to think that the Mallincam is so complex, that it might have to have it's own ASCOM driver.  You are really mixing Apples and Oranges, as Rock Mallincam always say.  Have you joined any of the nightskiesnetwork sessions I suggested? This will be my last message on this subject. 

        Tom Hilton
         
        On 5/20/2012 3:20 AM, Hristo Pavlov wrote:

         

        Hi Andy,

         

        I think that this will work but I am not convinced how benefitial it may be. Also in the case where the camera doesn't support any variable exposure - we will need to define what MinVariableExposure and MaxVariableExposure values are going to be. If they are the same value what would that mean. May be we need another property to indicate whether the camera supports variable exposures. Finally I am not sure that "Variable Exposure" is the right name for this. But I don't have a better one.

         

        Taking a step back, when thinking of defining an interface I always prefer to look from the users' point of view and what they want to do, rather than what the technology permits. Based on this I really don't see why a user will ever want to adjust the exposure of a video camera with a great precision rather than use a fixed set of exposures. Can you give me any reasons why someone may want to do that?

         

        Regards,

        Hristo Pavlov

        Sydney, Australia

         

        From: Andy Galasso <andy.galasso@...>
        To: ASCOM-Talk@yahoogroups.com
        Sent: Sunday, May 20, 2012 12:09 PM
        Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments

         

         

        Hristo,

        Regarding mixing fixed and variable exposure rates, one idea would be to add a pair of attributes like MinVariableExposure and MaxVariableExposure. Then the app could send any of the fixed SupportedExposureRates, or an arbitrary value between MinVariableExposure and MaxVariableExposure. That would cover MallinCams which would provide a set of fixed rates plus a variable exposure range. Other cameras would just provide the set of fixed rates.

        Andy

         






        ExchangeDefender Message Security: Check Authenticity
        Complete email hygiene and business continuity solution available from TiGra Networks
        Before replying, please review our email policy



      Your message has been successfully submitted and would be delivered to recipients shortly.