Star Alignment Bug?

[jeffweiss9]

I'm trying to combine raw images from February-March 2015 with raw images that I collected recently with PI 1.8.5 (01.08.05.1353) on Win7 64bit.  When I use the Star Alignment Process to register the 2015 images with the reference image from 2018, it results in all the 2015 images being vertically mirrored instead of actually registered with the reference image.    Surely people want to combine new raw images with other raw images from a few years ago.  Is there a work-around to get Star Alignment to register old raw images properly?  (I'm trying to register the old .c.cc files which are .xisf the new reference).
Thanks,
Jeff

[bulrichl]

Hi Jeff,

when you say 'raw images' - are that FITS files? I suppose that you are using a different image acquisition software than before. It is possible that one of these softwares mirror the images. In Format Explorer|FITS you can adjust how PixInsight will open the FITS files (regarding the coordinate origin). However, be careful. When you change this setting, of course also the corresponding calibration raw files have to be processed again to the MasterFiles in order that they match properly.

Bernd

[jeffweiss9]

Hi, Bernd-
No, I mispoke saying the "raw" images (which were FITs files collected by TSX in 2015).  I'm trying to use Star Alignment to register the old calibrated .xisf files: That is,  the .c.cc BatchPreprocessor files that are calibrated, cleaned up with Cosmetic Correction, but not yet registered, so they can be registered once with the reference frame for my  new data (and new camera, pixel size, etc).  I got the same result with the registered .c.cc.r files, but didn't try the original raw FITS files (but didn't want to have to recalibrate them).  If I can find my old darks, I guess, worst case, I could rerun the current BatchPreProcessor script on the original FITS files. That probably would take less time than I've already wasted unsuccessfully trying to get the old cc files register to the new reference frames.
-Jeff

[bulrichl]

You want to align images that were taken with two different cameras, right? No problem for PixInsight, I did exactly that with images of a Canon EOS 600D (= Rebel T3i) and a ZWO ASI294MC Pro.

However, it must be assured that the coordinate origin of these images (after they are opened in PixInsight) is the same. For FITS files there is no standard, and two possibilities exist:
1) coordinate origin (0, 0) of the image is top left or
2) coordinate origin of the image is bottom left.
In PixInsight, the coordinate origin is always top left.

If either the camera driver or the acquisition software behaves differently in this respect for your old and your new camera, the outcome would be mirrored images that cannot be aligned.

That means: you can use your old, calibrated images without any change. For the new camera, you change the setting in Format Explorer|FITS (so the coordinate origin is mirrored) and there should not be no problem anymore. However it is important that the calibration files of your new camera are processed with the very same setting as the light frames of your new camera - otherwise the calibration result would be wrong.

I hope that I explained it in an understandable way.

Bernd

[jeffweiss9]

Thanks, Bernd- 
   That certainly sounds like a plausible explanation for what I've been fighting and a potential solution. If I've understood it, then I really have no alternative to changing the FITS setting in Format Explorer so that the coordinate origin is mirrored in the new camera's lights, darks and flats. And then redo the BatchPreprocessing, Local Normalization for those, followed by then registering the old c_cc files to the new reference frame with Star Alignment.   Although I'm thinking that maybe I could alternatively resave the old camera's c_cc.xisf files as c_cc.fits files after changing the same FITS setting so that the old c_cc files (now FITS files) are mirrored to match the new camera.  Then I could re-resave them as .xisf files and restore the FITS setting to the PI standard for future use.  Do you think that would work equivalently? It seems those modified old c_cc.xisf files should then register to the new cameras reference files using Star Alignment. 
   For SB folks, (Juan et al.) it would be nice to have a switch available in the Star Alignment process itself that could, for each image in the list of input files, specify whether it should be left unchanged or mirrored prior to doing running the registration process. If I'm correct, that would be a good long term solution for people trying to process data from different cameras whose images have (0,0) in the LL corner instead of UL corner (i.e., are vertically mirrored with respect to each other).   It sounds like this must be a fairly widespread problem for people trying to use data from multiple cameras and Star Alignment should be able to handle it with the input specification by the user for each input file.
   FYI, both cameras in this case are from the same manufacturer (FLI ML8300 is the old one, FLI ML16200 is the new one) but I do remember that the images I captured (always with TSX Pro)  with the new camera had different mirroring properties and was puzzled about that.  If I recall correctly, one camera needed a vertical mirror step with the Geometry process to match TSX sky charts while the other camera did not.
CS/Jeff

[bulrichl]

Although I'm thinking that maybe I could alternatively resave the old camera's c_cc.xisf files as c_cc.fits files after changing the same FITS setting so that the old c_cc files (now FITS files) are mirrored to match the new camera.  Then I could re-resave them as .xisf files and restore the FITS setting to the PI standard for future use.  Do you think that would work equivalently? It seems those modified old c_cc.xisf files should then register to the new cameras reference files using Star Alignment.

Yes I think it is equivalent. However, I would prefer to 1) find out, which camera produces the correct and which produces the mirrored images and 2) leave the correct images and change the setting for the mirrored ones only, and NOT vice versa.

FYI, both cameras in this case are from the same manufacturer (FLI ML8300 is the old one, FLI ML16200 is the new one) but I do remember that the images I captured (always with TSX Pro)  with the new camera had different mirroring properties and was puzzled about that.  If I recall correctly, one camera needed a vertical mirror step with the Geometry process to match TSX sky charts while the other camera did not.

I really don't understand the reason why the mirroring occurs, if
- you didn't change the acquisition software (always TSX Pro) when changing cameras and
- you use two cameras of the same manufacturer (FLI in either case).
The camera drivers should behave analogously regarding coordinate origin - otherwise FLI would have to fix this! Perhaps the behavior is adjustable in the drivers?

Are you using both cameras in parallel for the future? In this case changing the setting in PixInsight is not a comfortable solution, it would be too confusing and error-prone. On the other hand PixInsight obviously does not provide a geometrical process that mirrors an image (don't know why), so one would have to write a script to achieve this.

Bernd

[msmythers]

Bernd

PI has a tool called fast rotation that does mirror. You could also use PixelMath. You can use those tools with a process container and the images in an image container to operate on a complete set of images as a batch operation.

It's also possible that during one of these 2 processing sessions that the Fits parameters had a different coordinate origins settings than the other.


Mike

[bulrichl]

Mike,

PI has a tool called fast rotation that does mirror. You could also use PixelMath. You can use those tools with a process container and the images in an image container to operate on a complete set of images as a batch operation.

You are right again, I'm really blind. I admit that I really did not look for it in the process group called 'Fast rotation', for mirroring is not a rotation .

But when thinking about it, I doubt that it is useful in this context to apply the process 'Vertical Mirror' at all. An astrometrical solution could be destroyed by applying Vertical Mirror. So my conclusion is: After the image has been loaded into PixInsight (including the correction if applicable according to the setting in Format Explorer|'FITS') it should already have the right coordinate origin (upper left corner).

It's also possible that during one of these 2 processing sessions that the Fits parameters had a different coordinate origins settings than the other.

Yes, that was my first suspicion as well. Then I thought that Jeff would have made mention of it if that applied, but it is still a possible scenario.

Bernd

[msmythers]

Bernd

Fast Rotations apply no pixel interpolations. They only move the pixels to a new location. Cardinal ( 90 degree movements) and mirroring are the only movements that this can happen I believe short of doing something with PixelMath and moving small groups of pixels.


Mike


 

[jeffweiss9]

Bernd, Mike-
    I am away from home for a few more days, so I can't compare the 2015 ML8300 and 2018 ML16200 raw FITS for the same target and be sure, but the 2018 FITS files from the FLI ML16200 are on the laptop I am using now. The pre-Meridian Flip images (Scope pointing on the East side) of the ngc2403 target in question agree with TheSkyX chart while I'm pretty sure the old FLI ML8300 images required a vertical mirror to agree. But I'll have to compare directly to be sure when I get home.
    Jeff
   
 

[bulrichl]

Jeff, no problem. Please keep me updated when you are back at home, as i'm really interested in this issue.

In my opinion the question that was not yet answered is important: do you continue to use your old camera, i.e. are you using both cameras in parallel for the future?

Bernd

[jeffweiss9]

Bernd-

I sold my old camera after buying the new one two years ago, but, as in this first try, occasionally I plan to use some of the old cameras "raw" data to improve SNR for a repeat target. I did use the old camera's data successfully once before, but in that case I just composited the galaxies in the old finished image with a wider-field view of the same galaxies in a finished image made with data from the new camera.
https://www.astrobin.com/290675/H/

Jeff

[bulrichl]

OK, that simplifies the problem considerably. I guess then you have all the information to get it working well.

Bernd

[jeffweiss9]

Back home and discovered that the old (ML8300) and new (ML16200) raw FITS images are related by a 180 degree rotation (= vertical mirror + horizontal mirror) to get the old FITS image to match the new FITS image (which matches the TSX star chart), not just a vertical mirror.  That leaves me further confused but I guess I can use a process container with the FastRotation process and an image container to reorient all the old FITS files (or maybe the _c_cc.xisf files, preferably).  Or I can just process the new data and composite the old and new finished images although that has got to be less optimal.  My confusion is: why didn't StarAlignment simply apply that same 180 deg rotation to the old images to match the new reference?  Instead it produced a set of images that still needed a vertical mirror to match the new images, so when the old and new images were stacked in ImageIntegration, the galaxy target (NGC2403) came out looking like a bow tie, instead of a galaxy.

-Jeff

Here is the actual text of the error report in the Process Console.  Drive D: is the backup drive; Drive J: is on the machine that was hosed (replacement coming).  The same c_cc.xisf files that it is asking for on Drive J: exist in a different directory on Drive D:.  I've looked at image headers and don't see anything containing information about drive J:

DrizzleIntegration: Global context

* Parsing drizzle data file 1 of 53:
D:/Vacation/New NGC2303/Batch/registered/Luminosity/ingc2403-Luminosity600.000secs-29.94C00000091_c_cc_r.xdrz
Reference dimensions : w=4500 h=3600 n=1
Input geometry       : x0=715 y0=660 w=3035 h=2370
Drizzle geometry     : x0=1430 y0=1320 w=6070 h=4740

D:/Vacation/New NGC2303/Normalized 031818/ingc2403-Luminosity600.000secs-29.94C00000091_c_cc_r.xnml
Loading image:
J:/ML16200/ngc2403/February 10 2018/Batch/calibrated/light/cosmetized/ingc2403-Luminosity600.000secs-29.94C00000091_c_cc.xisf
*** Error: J:/ML16200/ngc2403/February 10 2018/Batch/calibrated/light/cosmetized/ingc2403-Luminosity600.000secs-29.94C00000091_c_cc.xisf: No such file.

* Applying error policy: Continue on error.

[bulrichl]

Jeff,

wait, a 180 degree rotation is a completely different story than vertical mirroring. If the images are really rotated, you must not touch the setting in Format Explorer|FITS at all!

My confusion is: why didn't StarAlignment simply apply that same 180 deg rotation to the old images to match the new reference?

Yes, this would be the expected result.

Instead it produced a set of images that still needed a vertical mirror to match the new images, so when the old and new images were stacked in ImageIntegration, the galaxy target (NGC2403) came out looking like a bow tie, instead of a galaxy.

I can't imagine how this could happen.

Perhaps you can upload one of the raw FITS images each (8300 and 16200)?

Bernd