Hi Jasem,

Thomas ask me if I can give some idea about this issue., I think it is better to continue the discussion here if other have idea on the subject. Note that I not use a ASI camera myself.

For me the origin of the problem is the change that force the image width modulo 8 to be 0.
So my first idea is to check with ASI if this really also concern the binned size or not, I am a bit surprised of this requirement when it concern software binning as with the 183 in bin 4x4. This is probably the only way to fully fix the issue.

The temporary fix I do in CCDciel is the following.
When processing a request to change the binning, it look for the current image size (CCD_FRAME) and if the current ROI start from 0/0 and it's width and height are not the full size (CCD_FRAME.WIDTH.max) but more than 90% of the full size it send a CCD_FRAME_RESET before to set the binning.

This is not perfect, this not work if a small ROI is set, But this fix the issue with the calibration frames and for me this look more reliable than trying to remember what the size was the last time this binning was in use.

Another possible fix is the driver compute a size that work for (CCD_FRAME.WIDTH/ maxbinning) % 8 = 0 from the maximum size, this new value must be used as the default size, returned by CCD_FRAME.WIDTH.max and set by CCD_FRAME_RESET. This way it not need to change the size when the binning change.

Patrick

Patrick,

Thanks for the feedback. Regarding this (CCD_FRAME.WIDTH/ maxbinning) % 8 = 0, why is maxbinning used here?

I'm thinking:

driver_max_w = camera_max_w - camera_max_w % 8;
driver_max_h = camera_max_h - camera_max_h % 2;

and then the driver_max values are used as the maximum resolution throughout the driver. would this work?

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