Hi,

I just added the files you requested to the Onedrive I shared earlier.

I Examined some of the other test capture sequences I did and some of them have the same issue. The first image in the sequence is missing a few rows of pixels.

Earlier I mentioned, there was also a second image in a sequence that had this, but it turns out it was also the first of a sequence.

I have tried to reproduce the issue, but of course all tests do not have this untill now.

I also did a few tests and just like you, I could not reproduce the problem (yet). However, at least 3 ppl have experienced the same issue repeatedly, all 3 using an ASI camera.

The problem I described in a different thread does in fact seem to be similar:

www.indilib.org/forum/general/4521-wrong...d-in-ekos.html#34418

Fusis and Alfred diagnosed that correctly.

HOWEVER: I get the same warnings when I open a FITS image that has the CORRECT dimensions, i.e. 3520 pixels in the y-dimension.

So the stacking problem I get in DeepSky stacker and the FITS problem in PixInsight still are not exactly the same. The faulty dimension is a different issue.

If I may add, had this issue last week with ZWO 071 . Only one file out of 240 image had this issue . Just tossed that file out.

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 believe there is another problem with PixInsight in opening INDI Bayered images as well. Need to file a bug report about this.

Yeah, I did yesterday. Something changed in the latest version. So far I need to calibrate in Siril

Hi,

Just a little follow up. Since I started this tread.

I hope this helps narrowing down the issue. Although there seem te be more issues at play here.

I did some more sessions, and this is what I noticed:

Only the first light frame was affected. The file is also slightly smaller in size so there is actually less data in there.
I have never seen this when doing Darks, Flats or Biases.

I tried several Pre Processing tools, and I included the "failed" frame on purpose:

Siril - Will just stop Calibrating:

09:11:23: Reading FITS: file dark_stacked.fit, 1 layer(s), 4144x2822 pixels
09:11:23: Reading FITS: file dark_stacked.fit, 1 layer(s), 4144x2822 pixels
09:11:23: Reading FITS: file bias_stacked.fit, 1 layer(s), 4144x2822 pixels
09:11:23: Preprocessing...
09:11:23: Normalisation value auto evaluated: 540.84
09:11:24: 41630 pixels corrected (10 + 41620)
09:11:24: Reading FITS: file Lights_00001.fit, 1 layer(s), 4144x2816 pixels
09:11:24: imoper: images don't have the same size (w = 4144|4144, h = 2816|2822)
09:11:24: Execution time: 733.04 ms.
09:11:24: Reading FITS: file Lights_00001.fit, 1 layer(s), 4144x2816 pixels
09:11:24: Sequence loaded: Lights_ (1->40)
09:11:24: Closing sequence Lights_

PixInsight will throw the geometry failure and quit.

Astro Pixel Processor, will not complain, and just not calibrate the frame and continue.

For now I will just throw the first frame out, when I see a different size.

I have no clue as for the ambiguity message that PixInsight shows, but in the end it does not seem to affect the pre-processing.

So all is fine, except for the first frame (not always). And it would be nice to not get ambiguity messages in PixInsight when loading lights. I'm not adept enough to understand whether that is an issue in Ekos or PixInsight, side.

Cheers,

Marco

Guys, it looks like the issue is on our side. Apparently INDI crops the images by a few pixels. I reviewed my images from various dates and it looks like raw frames from December 2018 had correct size and geometry and starting from January 2019 all my frames are cropped with 1px in both axis. As the result I cannot use my darks, flats, biases taken before January 2019. If I retake them (I did last night) I can calibrate without problem, but the frames are missing these pixels (so it works because everything is cropped). I have discussed this briefly with Juan at PixInsight forum: pixinsight.com/forum/index.php?topic=13310.0
I think this is a critical issue, since we're losing data at acquisition.

Is this only on ATIK or elsewhere?

Looks like various CCDs. The other guys reported same problem on ASI CCDs.
In my case CCD captures images with missing 1 px in both axis (vs native CCD size). In other cases this account for 4px in one axis.

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.