Help with rotation of images and stacking in Pixinsight

Crash-dk
09 Apr, 2018 07:10
Hello everyone,

After a long period of waiting I finally got the chance to acquire some images of NGC 2903.
I had two evenings spend outside now. But I was confused because the EQ5 drove to the object different in the second night than in the first.

So my result is a rotated , mirrored picture to the ones from the night before.

I still tried to capture the same amount of images like in the night before and I almost got the same field of stars, though it's difficult to compare mirrored images to one another.

My question is now , how did this happen ? or why ?

Can Pixinsight work with these two sets ? or do I have to rotate and mirror them by hand ?

Thank you guys for your help and for sharing your knowledge.

Regards Dennis
MikeP
09 Apr, 2018 15:19
PixInsight will normally do all this automatically by aligning the images before stacking. Are the images rotated and mirrored or just rotated?
Crash-dk
09 Apr, 2018 18:17
It's not only rotated , also mirrored,
but camera position at the Teleskope wasn't changed though.

okay I'll try if it works , maybe I won't have a problem but I wanted to make sure if I'll get problems or not .

thank you Michael
RickS
10 Apr, 2018 06:18
If you use Triangle Similarity as the descriptor type for star matching, StarAlignment will work with mirrored images.  The BatchPreprocessing script uses Triangle Similarity by default so it should work with your data.  If you're running StarAlignment manually then make sure you change the descriptor type.  The default value of Pentagons will not handle mirroring - see the mouse over text for details.

Cheers,
Rick.
Crash-dk
10 Apr, 2018 07:06
Hello Rick , thank you for your help, I usually use the manually registration and alignment ,

I'll definitely try what you suggested.

So can someone tell why on one day the EQ drives "different" to one object than the night before ?

It is constellation Leo , it is in the S right now , by about 00:00 it is S-SW direction.

Mast also have something to do with the time i went outside , i was about 1,5 hours later on the second  night.

Regards Dennis
MikeP
10 Apr, 2018 07:19
Hi Dennis,

On a standard equatorial mount when the object moves through the Zenith (also called 'transit' ) you usually you have to 'flip' your scope in both axis as otherwise something will hit the pier soon. You probably imaged the target before then after the transit on those nights. If you have a planetarium app it will usually tell you when the transit occurs for a given object.
Edited 10 Apr, 2018 07:19
Crash-dk
10 Apr, 2018 13:27
Yeah that might be the reason.
I wondered when this happenes. I only use Stellarium, I'll check if i find something about it to avoid this problem again.

Thank you for your help.

Regards Dennis
RickS
10 Apr, 2018 21:51
But note that a meridian flip will only rotate images by 180 degrees.  It won't mirror them.  I quite like imaging both sides of the meridian.  It's like a huge dither!

Cheers,
Rick.
Jir11
11 Apr, 2018 01:08
Speaking of stacking images rotated do any of you know if there is a function in Deep Sky Stacker that will stack rotated images?
ruccdu
11 Apr, 2018 16:12
Deep Sky Stacker automatically rotates images.  Nothing to set.

Ron
Jir11
11 Apr, 2018 19:36
Excellent thanks Ron.
Crash-dk
11 Apr, 2018 19:51
Hey Rick !
so the meridian flip is the one that rotates the axis ? Or is that still something different now ? I'm not so firm with all the terminology , I only do smile

I capture with backyard eos.
and there is a button for the preview of already taken images that rotates by 180°.
i tried that , and it still was mirrored somehow.
what does that mean now ?

is it due to the meridian flip or is it anything else ?

Regards Dennis
RickS
12 Apr, 2018 04:28
Hi Dennis,

A meridian flip is what happens when the object transits and the scope and the counterweights switch sides.  This will cause a rotation of 180 degrees in the captured image.  It won't cause the image to be mirrored.

Mirroring would normally only be caused by a change in the imaging train or by differences in how software packages interpret the coordinate origin of the image in a file.  This is especially an issue with FITS format files where the standard isn't specific and some software assumes the origin is the upper left corner and some assumes the bottom left.

I'm not familiar with Backyard EOS and don't have a good theory about what is happening in your specific case.

Cheers,
Rick.
 
Register or login to create to post a reply.