"Why is a 2x2 bin of a 4144x2822 cmos supposed to be a 2072x1410 pixels frame? "

If the division was done on a floating point number and the result was subsequently converted to an integer that may have resulted in the loss of 1 pixel in the binned frame?

I've taken another look at the logfile. When a 2x2 bin is taken, ASISetROIFormat (2072x1410, bin 2, type 2) is set [2072x1411 would be correct]. Then frame buffer is set to 5.843.040 bytes (2072xx1410x2). The uploaded file size though is 5.849.280 bytes which doesn't fit the frame buffer. Is this where the pixels are lost? As I understand it, all subsequent 2x2 bins are taken in the same way.

Then, when the first 1x1 bin is taken, ASISetROIFormat (4144x2820, bin 1, type 2) " is called [4144x2822 would be correct] and frame buffer set to 23.372.160. Then again, the uploaded file size doesn't match the frame buffer. When the SECOND 1x1 bin is taken UpdateCCDFrame ASISetROIFormat (4144x2822, bin 1, type 2) " [CORRECT!] is called and the frame buffer is set to 23.388.736 bytes which corresponds correctly with the file size that is being uploaded. That's why the SECOND (as well as all subsequent 1x1 bins) are of the correct size.

Then, when the next 2x2 bin is taken, the issue comes up again. In my case, solver and focuser work with a 2x2 bin. It appears to me that every first 1x1 bin that is taken after either solving or focusing is affected by the issue. I hope this is helpful in chasing the bug in the code which to my utter regret I am unable do on my own.

I think you have hit the nail on the head. Perhaps one of the coders can have a look where in the code a floor division is carried out. IMO the most likely cause for this is that the pixel value for the y-axis (2822) is derived at some point through a floating point operation which leads a value very close to, but not identical to, but smaller than 2822. A value of 2821.999999999 would suffice if subsequently a floor division ( // ) is being carried out, which will lead to a rounding down to the next smaller integer. See the attached screenshot which illustrates this:



Alfred, where in the code did you find that expression: ASISetROIFormat (2072x1410, bin 2, type 2) and the equation from which the value for the frame buffer is being calculated? Look for the double forward slash ( // ), which is the command in python for executing a floor division, I suspect this is where things go wrong.

(But then again, I am not a coder, so all this may be entirely stupid. However, if it is, I have at least provided you all with a good laugh for a Sunday afternoon...))

Cheers

Jo

PS: This is another way how things could go wrong. If at some point a floating point number is being converted to an integer.



In both case, one ends up with 1410, i.e. the wrong value.

Jose, I didn't find it in the code, it was written in the logfile that I had posted. I'm not a coder, too. So I have no clue what makes Ekos come up with 1410 and 2820 pixels.

Alfred, I am almost certain you are correct. I also plate solve and focus using binning. Naturally then, the first image frame would be affected. However, I am binning 3x3 and my vertical resolution is 3520, but my first frame ends up as 3516, so 4 px are missing. My horizontal resolution is not affected: 4656.

I have been able to string together several simple Python3 operations that yield the faulty outcome in the vertical resolution and do not affect the horizontal resolution. The reason, I think, is that division by either 2 or 4, i.e. an even number, will yield an integer for horizontal or vertical pixel count. However, upon division by 3, only the horizontal pixel count will result in an integer, the vertical resolution will yield a non-integer (1173.333333333). Therefore, if at any point a floor division is being carried out, that number will then be rounded down to 1173.



If then subsequently that number is multiplied again by 3, followed by a another floor division by 4 and another subsequent multiplication by 4, the result is 3516, i.e. the wrong pixel count I am also finding for the first image in a sequence. The same operations do not affect the horizontal pixel count.



I would need to know where to look for this in the code. I believe the same operations in C++ would yield the same result.

Perhaps Jasem or Eric can point out the program module where these calculations are being carried out?

Best regards

Jo

Radek,

I am not sure this is a PixInsight problem.
The ATIK website lists the sensor geometry of the Atik 460EX as 2749x2199.



Looks like your FITS files are showing the wrong geometry.

Good news everyone!

I found and fixed the issue. First of all, not all frames are valid.

ZWO specifically states that Width % 8 must be always zero. So if your frame dimension violates that, it gets "corrected" by the driver. For height, it's Height %2 = 0

But the actual problem was in Ekos. Ekos sets binning first _then_ sets the frame. However, if the frame dimensions are the _same_, then nothing is set. When the frame are "auto corrected" by the driver, this is not reflected in Ekos when the binning changes. At any rate, please compile or use both indi-asi nightly driver and kstars nightly and report back if this fixes the issue.

El Corazon, now you killed me with this reply

So the problem is exactly opposite to what I have thought! I have been using this Atik 460EX for over 3 years and it always imaged at 2750px x 2200 px. This geometry was always like that in FITS header and actual FITS data. I haven't used any other software than KStars/Ekos & INDI ever since so I never compared it to any other source. Having said that I would bet Atik 460EX chip resolution was 2750px x 2200 px
Recently the atik driver maintained by Peter Polakovič has been replaced by Jasem and the new driver was included in regular updates as a 3rdparty driver. I have updated my systems and noticed that I cannot calibrate new light frames with dark and bias frames library, which I maintain for myself. I noticed that the resolution of the new images is 2749px x 2199 px. I took it as a bug in the new driver BUT the actual issue is that it is the old driver that was wrong with the image geometry!
The native resolution of Atik 460EX is 2749px x 2199 px. Period.
This solves the issue!

PS. I'm happy you enlightened me. However I will miss these lacking pixels... They sit in hundred of my images. I wish I knew where they came from

You're welcome, Radek!

Somehow, I did have an enlightened weekend.

I am sure that will change again, come Monday...

)

Cheers

Jo

So Alfred WAS right!

The binning introduced a division by 3, resulting in % not equal 0.

Good eye, Alfred!!

I'm glad to hear I - for once - might have contributed something helpful. As a non-coder I always feel like being somewhat retarded here. Anyway, I hope we successfully hunted down this bug. BTW, I've used Ekos 3 nights in a row and other than some missing pixels I have not experienced any issues. Simply wonderful!

Thanks Alfred and everyone who contributed to this thread!

Please try to test this change in the updated KStars tonight and see if the issue with binning is gone.