Jump to content

Canada's top-tier Telescopes & Accessories
Be as specific as possible when reporting issues and *ALWAYS* include the full version number of the application you are using and your exact *CAMERA MODEL*
NEVER POST YOUR KEY IN ANY PUBLIC FORUM, INCLUDING THE O'TELESCOPE SUPPORT FORUM ::: IF YOU DO YOUR KEY WILL BE DEACTIVATED WITHOUT NOTICE!
  • 0

Increase the surface area of the BYE API


icarson@nexus-desktop.com.

Question

On Astroman133's suggestion of a more detailed query regarding a post I made on the BYE forum  I am asking if it is possible to increase the surface area of the BYE API by providing access to more data and functions of the program. I have quite a specific reason which may prove too specific to be of general use so I understand if it is not possible/practical to implement and have thought of a "handraulic" workaround should this prove to be the case. Anyway, here's the situation...

  • I am writing a small piece of software which attempts to codify Roger Clark's thoughts on exposure by calculating the ideal parameters for each exposure in a capture plan and produce the capture plan as well
  • This will allow me to calculate capture parameters easily on-the-fly for changes in lenses, focal length, aperture, f-stop and ambient light pollution while shooting
  • The software is currently in scoping phase (excuse the pun :-) )
  • I need access to the camera parameters for at least focal length, aperture, f-stop and I suspect I will need the histogram from test shots requested by the software as well (GET calls to BYE, I believe the EOS Utility dll allows the histogram to be provided but not sure on this point)
  • Once linked to BYE I would like my software to be able to react to changes made on camera which would no doubt be captured by the EOS Utility dll which I'm sure is the underpinning of the BYE camera access (EVENTS fired by BYE)
  • Once a capture plan is created I would like to be able to export this seamlessly to BYE (access to RESET, LOAD and SAVE functions in BYE)

I don'y know if any of this is possible or practical but I would love to be able to create a seamless workflow between my concept and BYE, one which should optimize image capture.

In any event I shall be producing the software and will design it in such a way that should the necessary changes be made to BYE I will be in a position to take advantage.

Let me know your thoughts

Regards Ian

 

Link to comment
Share on other sites

  • Answers 4
  • Created
  • Last Reply

4 answers to this question

Recommended Posts

  • I need access to the camera parameters for at least focal length, aperture, f-stop and I suspect I will need the histogram from test shots requested by the software as well (GET calls to BYE, I believe the EOS Utility dll allows the histogram to be provided but not sure on this point)

If you are doing prime focus photography, BYE does not know the image focal length, aperture, or f-stop. Those are typically available from your mount, via ASCOM, or perhaps not at all when using a non-EF lens. If you are doing widefield astrophotography with an EF lens then the f-stop is known, but the focal length is in the EXIF data of the downloaded image. I do not believe that the aperture diameter is available from the camera, but you should be able to calculate it from the focal length and the f/stop. The aperture value provided by the camera is the f/stop value. BYE can create an EXIF text file, if configured to do so. You can parse this to get the parameters that you need, once the image has been downloaded. You can also calculate a histogram from the image's pixel data. BYE's histogram is calculated from the auto-stretched JPG data that is embedded in the RAW image. This may not be what you want. Calculating the histogram of the RAW data is problematic because it is not even possible until the image has been deBayered (converted to a color image).

  • Once linked to BYE I would like my software to be able to react to changes made on camera which would no doubt be captured by the EOS Utility dll which I'm sure is the underpinning of the BYE camera access (EVENTS fired by BYE)

You are somewhat incorrect about the relationship between the Canon EOS Utility and BYE. The Canon EOS Utility is an application that also controls EOS cameras similarly to BYE, but without any support for astrophotography. Both BYE and the EOS Utility use the Canon Software Development Kit (SDK) to manage the camera. BYE does not use the EOS Utility nor must it even be installed on your PC in order for BYE to work normally. Both applications are limited by the capabilities of the SDK.

BYE does not now fire events via its external API. It does, however, subscribe to events that are fired by the EOS SDK. Some of those events include property changes, such as changes to shutter speed, ISO and f/stop, shooting mode, etc.

  • Once a capture plan is created I would like to be able to export this seamlessly to BYE (access to RESET, LOAD and SAVE functions in BYE)

Are you expecting your program to be able to import a capture plan into BYE via BYE's external API? Of course, you could create a BYE-compatible capture plan that you could then manually load into BYE, as long as you have a Premium (or Trial) license. Of course you understand that this would require you to change your application should Guylain decide to change the format of his capture plan at some point in the future.

You started out your request by saying that you are "trying" to codify something. It may be too much to expect Guylain to buy into helping your with your experiment. instead, you could choose to experiment without integrating directly with BYE via the API. At least at first you could do this pretty simply with manually-defined input parameters while creating a BYE capture plan text file as the output. That would prove your concept, and nail down which parameters you need from the camera and when you need them, without needing to rely on Guylain to provide you with live data from BYE via the API. Once you know what you need and when you need it, you could better make your case for enhancements to BYE's external API.

These are just my thoughts as an experienced software developer and long-time BYE user.

Link to comment
Share on other sites

Thanks Astroman133 for the detailed response. I believe we're on the same page but I'm using slightly out of focus language which may be causing some confusion. Perhaps I could clarify...

  • I would never expect someone to blind develop against only a concept and I apologize if I gave that impression
  • I will produce the application to run independently of BYE but will design it in such a way that should there be a collaboration with BYE after I complete it,  the integration should be straightforward.
  • I said Canon Utility - I did in fact mean the Canon Software Development Kit - another apology
  • I am already using the EOS SDK for my Canon 7D in another project and would be coding against the SDK and working out the kinks for what I want so that I could then pass on what I needed if Guylain decided it was worth incorporating changes into the API
  • I think I'm correct in saying that the EOS SDK does not allow 2 separate connections to the same camera which is why ultimately I believe the connection data should come from the BYE camera controller as my application would only be a support program to BYE functionality
  • I came to the same conclusion as you regarding a manual loading of capture plans prior to any integration (I have a Premium license). That seems like a very practical workaround in the interim
  • I accept that capture plan formats may change over time - after many years of coding and systems integration it's clear that that's the nature of data integration :)

An old boss of mine used to say "show me - don't tell me",

Let me get back to you all when I can do just that.

Regards

Ian

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...

Important Information

This site uses cookies to offer your a better browsing experience. You can adjust your cookie settings. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies, our Privacy Policy, and our Terms of Use