Incompatible image geometry

PapaMcEuin

New member
I am having an issue with Image Integration. First, equipment and software. PixInsight 1.8.8-4 ( seems every latest update requiring a uninstall reinstall and read of too many issues with files created in prior versions having issues with newer releases). Canon T3i full spectrum modified, Orion 8" Newtonian Astrograph. Baader Coma Corrector, iOptron CEM60 mount. 1st night no guiding 60 second exposures because I only manually polar aligned using Canon EOS Utility saved as Canon Raw. Bought a 60mm guide scope mounted on the rings with losmandy plate so no flex. So 2nd and 3rd nights were guided using ASI174MM camera and polar alignment error per Sharpcap Pro was "excellent" 0 to 2 arc second error and due to limits with my light pollution I held at 3 minute exposures, used Sequence Generator Pro enabled medium dithering and it saved files as FITS.

Now, I had an issue with Image Calibration from the second night because I didn't properly calibrate SGP for the flats and it gave the same error on calibration when I attempted to use the FIT light image and the CR2 flats ( I was thinking do it this way incase I screw up the FITS method because I was having difficulty setting the right decimal number for the fraction needed based on the histogram from the Canon setting. I ended up having to go back and redo my flats the next evening as the camera hadn't rotated and used the SGP Flat wizard. 3rd evening no issues.

NOW... Everything has been ran through the BatchPreProcessing by its own evening of data, I have run Image Registation (Star Alignment)on all the images and they are now stored as XISF in the debayered folder for Image Integration. I had just 4 frames that it didn't register. Going to Image Integration, as soon as finishes the first night's data which originated in CR2 and moves to the first FITS file, it tanks with Incompatible image geometry. It is one pixel different. Why can't PixInsight handle this? I am using defaults all around. The images were processed using CFA checked, for the FITS files I had to manually set Bayer Mossaic to RGGB to match the Canon format because auto didn't work. As stated, Calibrate only with the process. Registration used all the defaults. Do I need to convert the CR2 files to FITS first and how to do that? Image W/H for both CR2 and FITS frames.

E:/PixInsight Projects/NCG 6888 Crescent Nebula/calibrated/light/debayered/IMG_0260_c_d.xisf Loading image: w=5202 h=3464 n=3 RGB Float32
NGC6888_180sec_1x1__frame1-1_c_d.xisf Loading image: w=5202 h=3465 n=3 RGB Float32
 
well for starters you can't mix FITS and CR2 files from SGP (during calibration) because SGP "rescales" the 14-bit data to 16-bits when saving a DSLR FITS file. this is true if even somehow both PI and SGP came up with identical pixel dimensions for the data.

secondly SGP has had to interpret the CR2 data in order to save it as FITS. it has used DCRAW to do this. PI used to use DCRAW but because dave coffin abandoned it, juan switched to libRAW (in order to gain support for newer cameras.) because both of these pieces of software had to reverse-engineer the CR2 format, the pixel dimensions usually differ a little bit, either accidentally or on purpose (recently libRAW made a huge change to how they interpret CR2 files from certain cameras, which has caused a lot of heartache around here.)

so anyway, as you can see from the lines you have posted, the geometries are indeed incompatible (the height is different by one pixel.)

however, as long as you got everything calibrated with flats/darks that match the lights (fits with fits and CR2 with CR2) you are out of the woods. it is OK for images being input to StarAlignment to have different geometries - StarAlignment will change all input files to have the same geometry as the reference image. i am not 100% sure what you are doing in the last paragraph, but it must be that you had different registration references for the FITS images and CR2 images when you ran BPP, so now some of your c_d_r files have one geometry and others have a different geometry.

so what i would do is just find all of your _c_d.xisf files in the various BPP folders for this project, pick the best one as a reference, and run StarAlignment manually. then take the resultant _c_d_r.xisf files and load them into ImageIntegration, and you're done.

rob
 
I ran night 1's data, all CR2 in BatchPreprocessing. No issues. I have ran night 2's data in BatchPreprocessing and yes, adjusted so all files are processed using FITS files. No issues. I have ran night 3's data in Batch Preprocessing no issues. For all of the Batch Preprocessing, I selected to calibrate only so no registration was automated. I dumped everything in the Registered folder to be sure I had a clean registration fileset. I took all data from each night that is saved in E:\PixInsight Projects\NCG 6888 Crescent Nebula\calibrated\light\debayered. I have 411 xisf files there. I ran all 411 through Star Alignment for registration. No critical errors, 4 files didn't find matches so now I have 408 files in the Registered folder. The failure occurs in Image Integration. I selected one of the FITS files as the registration reference. As that is the 1 pixel larger file, I wonder if that is where the failure point exists. You state that Star Alignment will change all input files to have the same geometry but is that a truncate function so if the reference is larger than the analyzed file, then there may be no change as there is no extra pixel column / row to truncate. I'll go back and run Star Alignment and then Image Integration over again and use one of the files that originated from the CR2 files and is 1 pixel smaller as reference. It will be a few hours before I have an answer if that makes any difference.
 
are you 100% sure that you are trying to integrate the newly registered images? it's not any kind of truncation; the input files are projected to match the reference image. people use SA all the time to upscale or downscale images of differing image scale.

you can prove this to yourself - open 2 images of the same object on your desktop, and then to one of the apply the crop process - set it to, say, remove 20 pixels from each edge (-20, -20, -20, -20). then take the unchanged file and set it as the reference and apply the process to the cropped image. you'll get a new image which is the same size as the reference image but with 20 pixel black borders.

or you can swap the roles of the target and reference image. this time you'll get an image back that is cropped just like the reference.

i just tried this experiment with an image that is 1 pixel shorter than the other and it worked fine, so i don't think there's any bug with small differences between reference and target. but if it keeps happening please upload one calibrated CR2-origin image, one calibrated FITS origin image and whatever images you used as the reference images to a file hosting service and post the link here so someone can take a look.

rob
 
Actually 100% sure. So I reversed the scenario as I stated and this time it works. Whatever you are doing in Star Alignment works if the reference image is smaller. I'll get some data uploaded tomorrow morning.
 
it works either way, again you can prove it to yourself by doing the experiment i just posted.
 
Rob... I wonder if there are some assumptions. I always include the reference image in the list of files to be registered....
Is it possible that if this did not happen, something could be up?
This seems like this all has to do with the reference.
-adam
 
idk - not discounting a bug which is why i thought the particular images were important to see. but there is no restriction a priori on the dimensions of a reference relative to targets.
 
Back
Top