In my hands, approximately 10% of the frames EKOS captures during an exposure sequence with my ZWO ASI1600MM-Pro randomly have a faulty geometry, in the sense that 4 pixels - and only 4 - are missing in the y dimension. I.e. it will show only 3516 pixels, not the normal number of 3520 pixels. That makes those frames incompatible for stacking in DeepSkyStacker.

I am wondering whether anyone else sees that problem and whether that is manifesting itself on the level of the ZWO or whether that is an EKOS problem.

Has anyone seen this?

Thanks for sharing your experience,

Jo

Hi,

I experienced something very similar as it turns out with my ASI294.

Check out this thread: indilib.org/forum/ekos/4517-can-not-cali...e-in-pixinsight.html

I think it is 100% the same problem. In my case it is always the first light frame that has a faulty geometry.

Also with the ASI294MC Pro sometimes a few bits missing. Although not 10% but more like 1% or less.
@herrhausen: i tkink also mine first image in the row.

Thanks, fusis,

I saw your thread, but that does not match my experience. From what I am reading, this concerns EVERY frame in your case and the problem is a different one.

In my case, only about 10% of the frames are affected and it happens randomly. Also, I can view those frames just fine, in DSS or in PixInsight, the problem only comes up when I try to stack them together with the 90% of the other frames that have 3520 pixels in the y-axis, not 3516.

It looks to me that that is a different problem, i.e. like the data transfer stream gets truncated and the last 4 "lines" are missing.

As I said, that happens randomly, but consistently. I am effectively losing 10% of my images every time.

Reply to Herrhausen:

Ah, "good", you are seeing the same problem.

I agree, it is USUALLY the first frame, but not always. But then it happens again randomly throughout the capture sequence.

I have not been able to find a pattern to it.

It might well be since I did not care to investigate the problem. I'll have to shoot a couple more sets in order to find out whether it's random. In Fusis case it doesn't happen to all light frames either.

I remember you use the scheduler and once in a while report problems. Are you sure these other (non-first) faulty light frames have not been the first ones after re-starting a session?

I think I solved the other problem I had where the image sequence would not start when using the scheduler after previously having manually run the same sequence. That may a problem with the aborted sequence still stuck in memory that does not allow it to be restarted from within the scheduler. I don't think that has anything to do with the 4 pixels missing.
One the sequence starts, exposures work fine and flawlessly within the scheduler. And the missing pixel problem also occurs in the middle of an otherwise smoothly running sequence. So I don't see a pattern that could connect these things.

Also, I don't get any of these warnings fusis gets when I open that frame by itself in PixInsight:

** Warning: The FITS format does not define an unambiguous orientation of pixel data. The coordinates read on the image may be wrong.

or that one:

*** Error: Incompatible image geometry

Do you get that warning?

Actually, you are right, Alfred!

It IS the same problem.

See attached screen shots.

I don't use Pixinsight but Regim aborted with an error message, too.

With Astrosnoesky it's 5 users now reporting missing pixels, all 5 using ASI cams (294,071,1600).

PixInsight did not abort, as the screehots show, it merely issued a warning.

I have never tried stacking my FITS files in PI, though, I am still using DSS for that.