Because if it is ATIK CCD, then the driver was changed recently to the officially supported version from ATIK, and everyone reported the size changes.

The only driver I'm aware of that cuts off pixels is GPhoto which is by design. If there is a camera that cuts off pixels, let me know how to replicate it. I have Atik, QHY, ASI, QSI, SBIG..etc here. but I can't replicate this problem. Now, there is another problem with PixInsight I'll report there.

Just to confirm, I have the ZWO ASI294MC Pro and I do not experience the issue described. Just the first frame issue, nothing wrong with the subsequent frames. I do not have experience from before January, as I am new to EKOS/INDI. But I can tell you that I am calibrating the EKOS frames with darks I took with Sharpcap in december.

I am on the nightly build btw.

Hope this helps.

OK, I have just tested it on Atik 460EX and ZWO ASI 120MM. Atik cuts off 1 px in every frame, ASI is OK. I think "first frame" issue on ASI294MC is another issue.

Tonight I had the logger on and ended up with several frames that were affected by this issue (ASI 294 Pro). Possibly they have all been "firsts" in a row. Normally, this cam's resolution is 4144x2822 pixels. However, during last night's session several light frames were taken in 4144x2820 pixels. Jupiter's Ghost 0008.fits is one of them. Logfile attached. You just have to search for "2820" and you'll see.

The only possible hint that I noticed while browsing the logfile is this:

[2019-02-13T01:36:10.663 CET DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI294MC Pro : "[DEBUG] Requested CCD Frame is (0,0) (4144 x 2822) "
[2019-02-13T01:36:10.663 CET DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI294MC Pro : "[DEBUG] UpdateCCDFrame ASISetROIFormat (2072x1410, bin 2, type 2) "

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

"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