×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

INDI ASI Driver Bug causes false binned images

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.
4 years 11 months ago #38386

Please Log in or Create an account to join the conversation.

  • Posts: 210
  • Thank you received: 104
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
4 years 11 months ago #38387

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
@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
4 years 11 months ago #38388

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
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
4 years 11 months ago #38389

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
A few thoughts...
When binning is set are you allowing the user to set ROI positions that are a fraction of a binned pixel?
For example with 4x4 binning would start coordinates of 2,3 be allowed? And does the ROI size have to be a multiple of the bin factor? What happens if the user doesn't do that? Would a ROI size of 10x10 with 4x4 binning give 2.5 pixels worth of data? Would it be 2, 4, 4 or 4, 4, 2 or 1, 4, 4, 1? Would you return a 2x2 array, a 3x3 array or even a 4x4 array?

The Standard Properties doesn't seem to say if CCD_FRAME is in binned or unbinned pixels, is this specified somewhere else?
4 years 11 months ago #38392

Please Log in or Create an account to join the conversation.

CCD_FRAME is unbinned. This standard is followed in all drivers.
4 years 11 months ago #38393

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
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?
4 years 11 months ago #38429

Please Log in or Create an account to join the conversation.

  • Posts: 210
  • Thank you received: 104
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
4 years 11 months ago #38430

Please Log in or Create an account to join the conversation.

  • Posts: 210
  • Thank you received: 104
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
4 years 11 months ago #38431

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
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
4 years 11 months ago #38432

Please Log in or Create an account to join the conversation.

  • Posts: 210
  • Thank you received: 104
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
4 years 11 months ago #38433

Please Log in or Create an account to join the conversation.

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.
4 years 11 months ago #38437

Please Log in or Create an account to join the conversation.

Time to create page: 0.743 seconds