Handling post meridian flip images

[ftheadley@comcast.net]

Greeting Group,

I recently experienced my first successful meridian flip with some images taken after the flip. Is it necesssary to rotate the images manually or will the batch preprocessing script handle the rotation automatically?

Regards,

Frank

[pfile]

should be handled automagically by the StarAlignment phase of BPP.

rob

[happydaddy]

Hi , i am real newbie in PixInsight...
 You mentionned BPP would take care of it. What if i don't use it and perform all the pre-processing manually ?  if i have only one set of flat, should i rotate 180 one of the set so all my lights match ?
Second question, if the meridian flip is handled manually and not automatically with SGP for instance, would that be also picked up by BPP ?

I apologize if the question is not formulated properly but i am not native english speaker and a beginner in astrophoto...

thx

[pfile]

there's nothing special about BPP (or WBPP) in this regard. BPP just calls the process called StarAlignment to do the registration... and when you do it manually, you use StarAlignment as well. so it will just work. StarAlignment can tell that it is looking at the same starfield even if one image is upside-down.

are you using a rotator? if not, there is nothing special about a meridian flip with respect to flats. you should use the same flats on both sides of the meridian. all that happens when you don't have a rotator is that the image is formed upside-down on the sensor after the flip with respect to the pre-flip images. however, the orientation of the camera to the telescope did not change, therefore the flats should not be any different.

automatic or manual does not matter. PI does not try to analyze any FITS header data to figure out if the image is taken before or after the meridian.

rob

[stevek]

The optical system remains the same whether the scope and camera is front, back, upside down or any which way.  PI will sort it out.  The only thing that must not change is the focus position and the orientation of the sensor with respect to the scope/filters.

[MikeD]

Hello all,

I'm new here as well and experiencing difficulty with Star Alignment and Integration.  Had difficulty getting Star Alignment to run successfully but once I did the Integration failed to rotate the images 180 for the subs taken after the meridian flip but integrated them anyways so the integrated image of M105, NGC 3384 and NGC 3389 ended up as a composite image of right side up and upside down in the same image.  It looks like 6 galaxies.  Has anybody else run into this same thing?

Thanks,

Mike

[pfile]

are you using BPP or doing it manually? ImageIntegration is not responsible for registering the images - StarAlignment is. it sounds like you may have integrated your calibrated but unregistered frames.

rob

[MikeD]

Not using BPP.  Registered via StarAlignment then Integrated using ImageIntegration processes.

Operating on the images with no other pre-processing such as Cosmetic Correction etc nor have I applied flats/darks/bias.

I'm just learning what the tools do and got an unexpected result, that's all.

Used the same sequence with another dataset and got a satisfactory result. 

I must be doing something wrong or have issues with bad data. Funny thing is DSS handles both datasets no problem.  Want to make PI work it's just a steep learning curve. 


Thanks

Mike

[pfile]

ok well, 2 things then... make sure you are only loading files with the suffix _c_d_r.xisf or _c_r.xisf into ImageIntegration. by default those are the filename suffixes that get applied by Calibration, Debayer and StarAlignment. since you want to integrate the registered images, the input files to ImageIntegration should always end with _r ("registered").

if StarAlignment is unable to register some of your images, there are usually 2 problems. with uncalibrated images, there may be a lot of hot pixels in the image and SA mistakenly identifies those as stars. in some cases it aligns all the images to the hot pixels, which means that the _c_d_r or _c_r output files are actually unregistered. the way to fix this problem is to increase the noise scales and the hot pixel detection controls in StarAllignment. another problem commonly seen is that the stars are too soft or too elongated and StarAlignment does not detect them. there are also sliders in SA to be more forgiving when detecting stars. in this case SA will fail to register the files and will not output a _c_d_r or _c_r file at all.

rob

[MikeD]

Rob,

Integrated with the _c_d_r files when I got the strange result.  I don't think it's a problem with the integration Process handling the post meridian flip images.

I think I have bad stars throwing off the StarAlignment.  I tried again with tighter parameters in StarAlignment and got the thing to work with star alignment failing on about half my subs.  I had previously made the parameters way too loose which ended up with registered images that had so many matches that I think it thought they matched upside down.
Strange though cause on visual inspection in Blink and Subframe Selector the stars seem OK.

I've had success with other datasets so I think this is just had an outlier case primarily caused by me after forcing StarAlignment.

Thanks,

Mike