Ah! I wondered about that @Jared thank you for explaining that to me. This is the first time I have ever looked at the ASCOM spec on the camera interface.
Thank you for emailing Sam, yours and Jon’s words carry a lot more weight than mine would. Very excited to see where it leads.
The reality of the other side of this situation is that you CAN set the offset as a developer. Ask SharpCap. That application can set the offset real-time while you are looking at an object on your screen, you can change the offset (brightness) as you see fit. The problem with this though, is that while this is a good thing for the consumer, this is a bad thing for the standards. The ASCOM standard has nothing that dictates how offset changes are managed. So since they have not defined that (which apparently we need to go to an early 2000’s forum that is largely ignored by most humans, to ask for), it is demonic to even think that implementing such things should be talked about. That mentality is archaic in the software world of today. That mentality has no place in 2017. In a world where DevOps and Cloud Services exist, that model looks about as old as a Model T Ford. I am not being abusive here, I am just stating my own perspective, Chris (if you read this).
The innovation in the market is grossly out-growing ASCOM. They cannot move fast enough with their tribune on Yahoo and in closed door conventions. The open source software push with hubs of energy like GitHub will put a quick end to this over a very short period of time. If you folks, Ken and Jared, wish to tie your wagons to the ASCOM train (which I wouldn’t blame you for at all) just know that the model used today is a thing of the past.
My suggestion: Go forth and conquer and tell ASCOM to figure out how to catch up.
Again… just my perspective, and not abusive at all. As a saying goes… The truth can hurt.
Yes you are being abusive and rude again. You know perfectly well that you are.
And more abuse of ASCOM. You have no understanding of what is involved in maintaining a standard. It’s different to mindlessly generating another version and breaking every other application. GitHub is a tool not a solution.
Once again:
##ASCOM HAS NOT BEEN ASKED FOR OFFSET
Hope that is clear enough. Let me know if you have difficulty with any of the long words.
Abusing ASCOM for not implementing something they have not be asked for is stupid. Continuing to do so is not acceptable.
Try to grow up and behave like a responsible, intelligent adult who wants to help, not a spoilt toddler.
Interesting - the QHY driver offers a list of preset gains and offsets. I wonder if it correctly implements the Gains property against that list. I’ll have to try to check that this evening. I can write a VB script to check it I think.
Tim
Yes I was wondering the same. Let us know if the presets (user-configurable) implement the Gains property.
…Keith
@rockstarbill we should be grateful for ASCOM and maybe having INDI later but as Jared said INDI may not be a panacea either.
I agree that the ASCOM standards modification process looks to be slow from the outside but I am not experienced with it as Chris is so I lean on his take on what it is really like. I also admit that I have to slow myself down, being a newbie developer to ASCOM (only ever developing an observatory conditions driver for my weather station), and think of the bigger picture here. The committee, as Chris stated, wants to ensure when V3 of the camera interface is created that it is worth having a V3 of it sitting out there and I respect that.
At the end of the day I am grateful that my AAS neighbors make such a great piece of software and that they are developers that care. The “Not Set” option is the perfect example of that caring part and there are many more examples like this over the years as we all know. I also side with Ken when he stated that they should not stop themselves from implementing a feature because a group of devices does something differently in how they use an ASCOM interface. The standard is the standard and that is what features have to be based off of. If Ken and Jared did not implement this new feature we would not have the chance to make it better at the driver level for our cameras. It is pushing the envelope to develop the driver in a different way, a better way possibly.
I have high confidence and respect for Sam also, he has always listened to us, he is one of the good ones as well in our hobby along with Chris, Ken, and Jared. I hope it is possible to make the changes needed when taking into consideration how other software uses their ASCOM driver. I know Sam will give it good thought. 
Tim, just use the one I showed above, change out the progid to the QHY driver first before running it of course.
First off everyone needs to just take a step back. This is a public support forum for Main Sequence Software products. Please be civil or this post will be locked and it will go away.
I’m very aware of this. We just have no desire to implement native support where an ASCOM alternative exists. To us the cost of implementing native support (likely a week or more) out weights the benefit (having a handful of people choose SharpCap over us). Unfortunately we have to decide where to put our resources as they are not unlimited.
ASCOM is wonderful! It provides an abstraction layer for hardware and SGP wouldn’t support near the amount of hardware or have a 10th of the features it does today without ASCOM being present. Sure we could support things natively (and do in some cases) but there is a significant cost in doing so. If we had to add support for each device in our application you could bet that other features would not have progressed any where near to what they are today.
While we certainly support ASCOM we don’t EXCLUSIVELY use it either. But it is certainly our preference to move hardware into the “supported via ASCOM” column rather than spending a week or more implementing support of a device that we may or may not have on hand. Personally I would rather work on features for SGP that all our users get rather than implementing a driver that maybe 5% of users would use. This is not uncommon in the software world. Same reason why printer drivers exist today… rather than having to buy software that worked with your specific printer (this used to be the case!)
Is ASCOM perfect? No. Is INDI perfect? No. Do both of them solve the same problem in almost the exact way (from a client perspective)? Yes. So really I don’t see INDI as being the magic bullet here. I also don’t see ASCOM as being behind, there are options for adding “non-interfaced” calls into the device. So you could create an “Offset” field in the ASCOM device right now if you wanted to.
Thanks,
Jared
Jared, any response from Sam yet?
I am honestly wondering if they would even be able to accommodate here. They have a universal ASCOM driver that supports all of their USB 3 cameras. Most often than not, those cameras are geared more towards planetary/SSO imaging than DSO imaging. That makes me wonder how practical implementing the Gains List style approach to gain would be, as it seems that would be more counterintuitive for planetary imagers.
Of course, I also don’t get nearly the frame rate with ASCOM as I do with the DirectShow driver…so, maybe it wouldn’t be an issue. Anyway…I am kind of curious if/how they could support the Gains List approach rather than the min/max gain range approach, and whether that might break backwards compatibility with existing apps and users… O_o
That is the challenge of course, how other software (and users) use their ASCOM driver. It may not be feasible in the end to use the Gain\Gains model for everything but at least Jared tried to ask. Maybe Sam would not mind having two revisions of the driver, one that behaves as the current one does (GainMin\GainMax) for planetary users and backward compatibility and another that uses Gain\Gains for SGP users. That is a lot to ask though and I would not think less of Sam at all if he elected to just stand pat with how it is now.
It would be wonderful to use Ken and Jared’s new feature with our camera’s but if it is not possible now it is just not possible. We have our “Not Set” feature to fall back on.
If you could implement something like the ISO for each event that would be great. Currently QHY lets you predefine a few gain/offset values which make initial start up a breeze.
If Gain/Offset (even pulling off the predefine values) could be implemented in an event thats what I would like. Like use Preset 1 (Gain 0/Offset 30) for LRGB and than preset 4 (gain 20/offset 75) for Narrowband that would rock. One issue is that QHY and ZWO have different gain/offset scales. QHY goes from 0 to 40, ASI I believe goes from 0 to 300.
I would love to see this too. I have a QHY163M on the way.
Right. Something like this… Right now ASCOM does not provide access to Offset and SGPro does not have access to any of the QHY specific settings properties… so this would be a future ask. Today, @Chris and Bob Denny were kind enough to include us in an ASCOM discussion regarding the discussion here.
Not correct, at least as far as I was concerned. I was on holiday and know nothing about this. The internet in Northern Finland is a bit tenuous - at one point my phone thought I was in Russia.
Here’s a nice photo, green snow.
It was me (Bob Denny) that included you in the discussion. I didn’t lknow that Chris was on holiday at the time (sorry Chris). My objective was to solicit comments on this idea from by the people who were involved in finalizing the ASCOM Camera standard back in 2009. I included you so you could see their comments. Hopefully this brought some perspective.
