Will test as soon as possible, but the weather forecast here for the next 10 days shows only clouds....

Thanks for fixing this so promptly, Jasem!

I don't want to proclaim victory too early but I tested the latest code indoor and the results are perfect. I was focusing in 2x2, shot a few 1x1bin frames from the queue, solved in 2x2 and again shot a few 1x1bin frames. They all were of the correct dimension. I expect the same results in the night sky. Many thanks for sorting this out!

Hi,

I wanted to tell you that this issue was solved. I did test it the night after the driver was fixed. And indeed no more missing rows of pixels in the first frame after a change of binning. But the last few nights I have been really struggeling with the ASI drivers. I get loads of crashed asi drivers messages, mostly when trying binning 4x4, 3x3 and also 2x2. If I refrain from binning and stay on 1x1 all is fine. The images taken when binning 3x3 and 4x4 look very strange, there are slanting bands in the image. Mostly after one image is taken it crashes the asi driver.

I use an ASI294MC.

Yesterday also the ASI385 crashed the driver, this was after guiding fine for some 20 to 30 minutes. This is new, I did not have this before yesterdays update to the nightly builds.

I will post Logs later today, I can not reach them at the moment. But I wanted to let you know. Maybe there's more users affected?

FYI I tested binning on a laptop with sharpcap. Nu issues with binning there, so it's not the camera (I guess).

I agree with you that that problem was solved. All downloaded images now have the correct dimensions in my last two tests.

I also agree that there is (probably) a problem with binning 4x4, I saw a similar distorted image, but did not investigate further at this time, since everything was working fine with 3x3 binning.

But the much bigger problem is this:

indilib.org/forum/ekos/4670-solver-fails...scheduler.html#35492

Whatever changes were made have now completely killed the scheduler. Because, if the alignment module can no longer capture an image, it obviously cannot align and if it cannot align you can't use the scheduler, unless you are into collecting images from random sections of the sky.

Here are the logs from 2 nights ago. Although I am not certain what all the lines mean, it is very clear that something is very wrong when half the log consists of warnings that something "failed for trixel 32"

www.dropbox.com/sh/jsu99h7geo6sgss/AACUm...76w67XR5ETf5gUa?dl=0

This concerns the KStars version (nightly) Jasem refers to in his post 35159.

Jo

PS: To reemphasize: The problem with the alignment module not capturing an image occurs ONLY in the scheduler. If the alignment module is used outside the scheduler, it works fine. So only users who have tried using the scheduler will likely have experienced this bug.

I think it is better to start a new topic: ASI294Pro Binning issue 3x3 and 4x4, so I did please look for it.

I have been OK with this finding for last couple of weeks.... However my FITS files from Atik 460EX are showing 2750x2200 geometry (+1 in x and y).
Anybody facing this issue again?

When you take one of the FITS files and open it in Photoshop or Gimp, how many pixels does it show there when you select Canvas size and image size?
I.e. is the header right or not?

Both FITS header and actual resolution (checked in PixInsight and Gimp) are 2750x2200.

From your previous post I understand that the FITS header shows 2750x2200. But in the PI console upon importing the image PixInsight reads 1 px less in each dimension. That is also the dimension listed on the ATIK website.
If the ACTUAL pixel COUNT (not FITS header) shows 2750x2200 then the information on the ATIK website must either be 1) wrong, or 2) the resolution was rounded up to the next number that was divisible by 2, or 3) the driver that PI reads out states the wrong value in the console (as does the website), or 4) PI entered the value provided to it by ATIK into the database it uses for its calculations and disregards the FITS header AND the actual pixel count.
Looks like that cannot be solved without input from ATIK. You need confirmation of what the actual pixel count of the sensor really is.

I know this Pixinsight error. To calibrate images Pixinsight needs, that all images (LIGHT, BIAS, ....) have the same image geometry (width and height in pixels). Your image may have different sizes.
This can possible origin from this bug, which came back in my INDI installation:
indilib.org/forum/general/4889-false-ima...gain-please-fix.html

Thomas

This is NOT PixInsight error. It has been discussed on PixInsight forum and the issue is for sure related to actual geometry written to a FITS.
There is full consistency between actual image geometry and FITS header, however there is no consistency at all between actual image geometry and CCD specs on ATIK site.
Does anybody here use ATIK's windows software so we can confirm image geometry using native application? I don't even have a windows machine to try it on.