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

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

Expand Messages
  • Tim Long
    Ah now that’s interesting. On the first computer I used, the page background came out the exact same colour as the hyperlink, which is why I didn’t see it.
    Message 1 of 85 , Apr 28 7:10 PM
    View Source
    • 0 Attachment

      Ah now that’s interesting. On the first computer I used, the page background came out the exact same colour as the hyperlink, which is why I didn’t see it. I saw the red text about unblocking the download and was confused by that because there was no obvious file to download. My other computer displays the page differently, with a lighter background colour, so I can see the link.

       

      Regards,

      Tim Long

       

      From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Hristo Pavlov
      Sent: 28 April 2012 00:02
      To: ASCOM-Talk@yahoogroups.com
      Subject: Re: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments

       




      Hi Tim,

       

      Try the link at the top of the page. It contains a zip file with both the generated CHM file and the interface defined in a C# file.

       

      Regards,

      Hristo Pavlov

      Sydney, Australia

       

      From: Tim Long <Tim@...>
      To: ASCOM-Talk@yahoogroups.com
      Sent: Friday, April 27, 2012 9:30 PM
      Subject: RE: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments

       

       

      Hristo,

       

      My first thoughts are that this seems to be a very well-reasoned and well-presented proposal. Its excellent how you have presented the reasons for your decisions and I think I agree with all of them. I don’t think you’ve actually published the interface definition though, the document you linked to only contains your notes… J I particularly like the way you have presented the use cases and kept the proposal to the minimum necessary to meet those use cases.

       

      With ICameraV2, one area in particular that I’ve noticed people having issues with is accessing the ImageArray. It would be useful if the proposal could be very clear about data ordering within the array and how this is accessed from various languages, preferably with code snippets. Good candidates are VBScript, Jscript, C# and VB.NET which covers access both from COM and within the .NET Common Language Runtime. I’m sure the community will be happy to help with this if you aren’t familiar with all the languages.

       

      Once you publish your actual interface proposal, I’ll give more feedback.

       

      --Tim Long

       

      From: ASCOM-Talk@yahoogroups.com [mailto:ASCOM-Talk@yahoogroups.com] On Behalf Of Hristo Pavlov
      Sent: 27 April 2012 11:42
      To: ASCOM-Talk@yahoogroups.com
      Subject: [ASCOM] New IVideoCamera (Draft V1) - Request for Comments

       



      Hi All,

       

      Please find below my initial draft for a new ASCOM interface for controlling video cameras:

       

       

      Your comments are highly appreciated!

       

      Regards,

      Hristo Pavlov

      Sydney, Australia




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

       

       





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



    • 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.