So Alfred WAS right!
The binning introduced a division by 3, resulting in % not equal 0.
Good eye, Alfred!!
You're welcome, Radek!
Somehow, I did have an enlightened weekend.
I am sure that will change again, come Monday...
Kaczorek wrote: I think it's a PixInsight issue.
I have just tried to calibrate my frames collected recently and... very strange thing happen. I cannot calibrate because PI reports "Incompatible image geometry" even though the files are just fine.
FITS files are <strong>2750 x 2200 px</strong>, and FITS header confirms this size. However when I try to calibrate the frames PI reads them as <strong>2749 x 2199 px</strong>. 1 pixel missing in both axis!
I inspected the frames and they ARE correct size and this is PixInsight that is wrong. I'm using the latest PixInsight 01.08.06.1457 Ripley (x64) running on Ubuntu 18.04 x64.
Have you seen anything like this?
UPDATE: Siril has no problem with calibrating the images whatsoever.
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.
El Corazon wrote: Alfred, where in the code did you find that expression: ASISetROIFormat (2072x1410, bin 2, type 2)
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 an uneven number (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.
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?
Herrhausen wrote: 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 to an integer, 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...))
wcreech19 wrote: It's the same mechanical assembly as used in QHY's polemaster. It should be pretty dang close to being aligned to the RA axis but maybe not? IDK. Has anyone had a similar issue with the ekos PA module? It always consistently putting me 7-8' arcminutes out of alignment for some reason. The good news is that it's consistent but obviously, it would be nice if we can get it closer to 1'.
So, what if I adjusted the polemaster mounting bracket so that when Ekos throws the RA axis vector on the image, the RA axis is exactly dead center of the image? Last time I used it, I noticed it wasn't exactly dead center but it was fairly close. (Maybe 7-8' arc minutes?!) There is some room to adjust it since it's assembled to the camera with only one screw (the center screw on the back of the camera). Is that worth a shot or should it even matter at all.
I am wondering whether this might be an iOptron driver problem. I have a similar issue with my iOptron SmartEQPro+. My Atlas Pro mount, by contrast, aligns just fine using the EQMOD driver.
"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?
Just thought I share my experience with Jasem's autofocus tool, using a very simple home-built autofocuser with a timed motor (not a stepper motor) and Shoestring Astronomy FCUSB as the driver. I focused using Jasem's tool and then checked using a Bahtinov mask. Here is the result:
Couldn't me more perfect, I would say.
PLEASE, Jasem, do NOT give up on the autofocuser. It is (almost) PERFECT as is!
knro wrote: Sebastian,
This is awesome! Many users have requested this feature before. Though I am quite spoiled with the autofocusing and my bahtinov mask is collecting dust now
Please don't give up on the autofocuser. That works fantastically and is indispensable when running an automated image acquisition sequence.
Both have their place, but I don't see how a Bahtinov mask focusing mode could be integrated into the scheduler.
Birthdate01. 01. 1960
About meStarted astrophotography with the eclipse last year. I never knew what was possible these days. Now I'm hooked.
Unfortunately, I am living in a white zone, so the only solution to getting acceptable pictures is to collect as much light as possible above the background. That's where the Ekos scheduler can become a life-saver!
Great job, team!