Jasem,

This is because the driver apply a size reduction based on BinnedWidth % 8 = 0

Look at Thomas log above with the ASI1600.
It start with bin 1x1 and width=4656
when it set bin 4x4 the image width change to 1160 = (4656/4) - ((4656/4) % 8 )
As ccd_frame.width is always unbinned it is set to 4*1160 = 4640

So if MaxBinning for this camera is 4, the value for ccd_frame.width.max must be set to 4640.
This width work for bin 1x1, 2x2, 4x4 without resizing.

Patrick

Thank you Patrick, that cleared it up. I submitted a change (v1.3 of the driver) and let's see if it resolves the issue.

I would like to test it, when does it come on ubuntu via ppa?
Thanks

Thomas,

I see indi-asi-1.3 is now available in the nightly ppa : launchpad.net/~mutlaqja/+archive/ubuntu/indinightly
When testing, beware you probably have to re-do all your calibration frames because of the change in the default image size.

Patrick

The weather is not clear at the moment in germany. I have tested it in the lab. It works, but I cannot agree to this solution.
Fancy somebody buys a ASI Cam an reads in the manual that it has a 5496×3672 pixel geometry and he uses INDI and sees a 5472x3672.
Furthermore ccd images made with ASCOM and INDI are not compatible any more. They were compatible before this BUG.

Thomas

I actually agree with Thomas. Perhaps I misunderstand the complexity of this issue but shouldn’t sensor dimensions when binning always be computed straight from the actual dimensions? Meaning that when one switches from 1x1 to 2x2 to 4x4 and then back to 1x1 via 2x2 that all the dimensions should be computed from the “original” (meaning true) sensor dimensions dividing by the binning factor (and possibly applying %8 ) instead of the current implementation?


Wouter

Well, this is what Nightly releases are for, to test these changes. So I can either revert the changes or make them as an option. Though I'm afraid an "option" will only complicate things for end users who will end up with incompatible photos with and without this option.

@Thomas: I also agree, reducing the factual CCD size creates incompatibilities with other non-INDI applications.

When you take a look into driver, you can see the problem. In the current implementation, changing the binning tries to keep the currently set ROI (modulo the factor discussed above). That leads to exactly the situation described in the bug. Take the ASI-1600 with its 4656x3520 CCD and start with the full frame and 1x1 binning. Now reduce to 4x4 requires to reduce to 1160x880 and not 1164x880, since 1164 mod 8 = 4.

Until here everything is fine. But when you change back to 1x1, the ROI ends up in 4460x3520 <strong>unless</strong> you reset the ROI to the full frame at the same time.

The question is, what is the expected behaviour of changing the binning. Would it be OK to reset the ROI - which might have been an entirely different one before changing the binning?

@Jasem: I would opt for taking back the change.

Wolfgang

You nailed the issue. If we assume we're just dealing with the maximum resolution of the camera, then this is n easy problem to solve. But the ROI could be anything, so you cannot assume that when the user returns to 1x1 binning, that he wants to return to the full resolution of the camera and completely discard the ROI that was set before.

Yes, keeping the ROI when changing the binning is all the difficulty here.

With ASCOM this problem is always handled by the application because the ROI is set in binned pixel, so every time the application change the binning it must also set the corresponding ROI.

It is very convenient with INDI to have the ROI handled by the driver and up to now this worked fine, the application do not need to adjust the ROI when changing the binning.

I thing we must clearly define what we need before to try a next iteration of the driver.
Are you OK with the following:
Clearly the most important is to always get the same full frame size for a given binning, nerveless what binning was previously set.
For small ROI, like the one you can set for focusing or guiding, it is less important if the size can change by a few pixels when the binning change.

In this case it is possible the driver compute a array of maximum size for each binning part of the initialization.
Then when the binning change it look if size=maxsize[oldbinning] and in this case it set the new size to maxsize[newbinning]

Do this make sens?

Patrick

@Patrick: I'm fully with you, better discuss all pros and cons before changing.

The proposed solution covers the situation with the full frame and binning, but makes it at the same time more complicated to implement.

The core of the problem comes from the fact, that changing the binning can have a side effect upon the set of pixels used for capturing. So expecting that going back and forth and ending with the exact same pixel set is simply not feasible. It might be the case, but we cannot rely upon it.

That's why we have to decide with wich tradeoff we want to live.

Let's take the EKOS implementation as example. When a frame is captured, first the binning is set and afterwards the ROI in the 1x1 resolution. This has the nice effect, that from a GUI perspective you can go back and forth with the binning without changing the ROI. The downside is, that you do not see, that for some situations the ROI is in fact smaller as you set it. The client currently does not read the ROI back after it set it - which is good. Otherwise we would loose the information about the original ROI size.

But maybe we first try to clarify our expectations and priorities before we discuss possible solutions.

From my perspective, top priority is, that I do not loose the full frame setup when I change binning. I can live with the fact that after I change the binning I need to reset my ROI.

- Wolfgang

If I understand correctly then the current implementation sets a ROI by default in order to avoid ending up with a smaller ROI after setting binning to something else than 1x1. But this means that it is possible that not the full frame is used at 1x1, even if binning is never changed. I never change binning and always shoot at 1x1 and I expect that to be at full frame.

If I'd ever change binning then I wouldn't mind having to set the ROI when I change back to 1x1 binning as long as this is made clear to me in some very obvious way in Ekos, e.g. a popup. I'd find a situation where I ended up with a smaller ROI at 1x1 without a warning or other notification unacceptable.


HTH, Wouter