CCD_FRAME is unbinned. This standard is followed in all drivers.

Another idea: what if we separate the outside behavour from the internal one? That would mean that we could set the ROI arbitrarily an the driver dynamically derives a maybe slightly smaller ROI for capturing without making this visible on the interface?

Example: we set the ROI to 101x51 (unbinned) and the binning to 2. As soon as a frame is captured, the camera reduces the width to 100x50 ( or 96x50 in the ASI case). But if we ask for the set ROI, the answer is still 101x51.

Or, other version, the driver creates an error forcing the user to choose manually an appropriate value.

I took a quick look into the implementations of other manifacturers. None of them has a side effect changing the ROI. Either they throw an error or their firmware captures this and find its own solution. It seems like we are discussing an ASI specific behaviour here, which I think from a framework perspective we should avoid.

What do you think?

Wolfgang,

Thank you for this explanation, yes keeping the wanted ROI in the application, ignoring the change send by the driver and setting the ROI every time the binning change probably solve the issue. I have no problem to update my application to work this way.

The application have to send a CCD_FRAME_RESET jut after the camera connection to get the ccd full size and after that they must ignore every CCD_FRAME receive by the driver. and work only with the internal ROI to send it after the binning change.

But we must be sure all the camera driver can work this way and this must be specified in the documentation because this is a bit of an exception to the INDI principle.

Or another idea that come while writing this. Is it possible the ASI driver keep this modulo 8 size internally and not send the CCD_FRAME change to the client? It also as to keep an internal buffer for the ROI to set it back to the camera after the binning change, so doing what you do at the application level in the driver?

Patrick

Wolfgang,

We are writing at the same time and I was replying to your previous message.
But it look like we get the same conclusion

Let see if this can be done in the ASI driver.

Patrick

Patrick,
Great to hear that we came to the same conclusion

What do you think is better: letting the driver automatically selecting a compatible subset or throwing an error?

- Wolfgang

I think most of the other driver set a compatible subset, because I never get an error in this case.
My application only force even values for the ROI start point and size to not shift the color with a bayer pattern.

Normally it must not hurt the application to receive an image that is not exactly the same size to what was requested because the real image size is read from the FITS header.

Patrick

CCD_FRAME set must be updated because that is the size used by INDI to record the FITS header info and write the actual FITS image.

I thought (and for a while went for) just raising an error, but this is very user unfriendly since why would a user expects error for just requesting a 2x2, they have no idea about the module 8 issue not they care.

Great, I'll then disable my last change in the driver.

I see, there is a solution. Thanks.
When will it be in the stable PPA

Yes, for me this is clear now.
Maybe a note can be added somewhere in the INDI client documentation, maybe in the Standard Property page, that changing the binning can change the CCD_FRAME value, despite it is unbinned pxiel.

Thomas, the stable ppa is already without the change that reduce the maximum frame size in binning 1x1, so you can install this version now.
You can check the frame size is 4656x3520 after connection to be sure this is this version.

Then you can install this test version of CCDciel that include the new way to handle binning and ROI:
vega.ap-i.net/tmp/ccdciel_0.9.55-1550_amd64.deb

Please report in the CCDciel bug tracker if you get any problem with this version.

Patrick

Thanks Patrick. I checked and the stable Linux build indeed gives 4656x3520 for my ASI1600MM and the nightly build gives 4640x3520.


Wouter

AIUI this camera hardware requires that the image width (and start X?) is a multiple of 8 pixels, so widths of 8, 16, 24, 32 etc. If the user asks for 20 then could the camera be asked for the next multiple up, so 24 pixels, then the driver software extracts the the required data from the larger frame supplied by the camera?
I understand this is more complex for the driver but the client would get what they asked for.

Hello Patrick,
I can confirm, that it works with your provided version.
Thomas