Unfortunately I don't have a normal mount, but a German one. So I'm forced to lose precious hours when the object to be photographed is in the best position, on the meridian. I have neighbors and I can't make too much noise, so I have to reverse the side by hand, with huge problems in sync and solvin plate. But that's another discussion. The problem is that I also have to remember to enter in to the indi drivers of the two ccd cameras (120mm and 533mc) and manually invert Hflip and Vflip (I certainly don't start rotating them 180 degrees every time). And I have to remember which light and dark are flipped, because it is not recorded in the header of the FIT file (or at least I think). Is it possible to automate all these operations? you know that if you debayerise a flipped image the red and blue channel are inverted (for normal, RGGB or auto, for flipped BGGR), so this process is very important. And how about to have flip information inside the file?
German equatorial mounts are very popular among imagers, I've only had those as well. Haven't had any issues registering subs taken from either side of the meridian, the stacking programs handle that automatically by themselves. No need to manually flip the images. and you only need one set of darks, biases, flats etc. Which program you use that can't handle non-rotated images automatically?
Stacking programs DO NOT automatically handle files that have been flipped 180 degrees or mirrored. If you calibrate light frames (blue) with inverted darks (red) you get a big mess. The ideal solution is never to rotate the files, but prefer the physical rotation of the ccd camera. You know, if you debayer a rotated file in pixinsight the result is blue star become brown, red become violet., B channel and R inverted. The question I ask is addressed to the Ekos developers: how to automatically manage the h and v flip? in the indi driver it is possible, but in the work sequence in Ekos it is obviously not possible. currently. Also the tag "ROWORDER" in the FIT header is always written "TOP-DOWN" even when the file is flipped 180 degrees!!. And also if the stacking software uses this data (and it doesn't), it is still wrong data.
my 2 cent: I'm stacking with APP, and I never worried about the orientation before and after meridian flip. It just works, APP orientates the pictures. As far as I rememebr also SIRIL do it that way. I just throw all the pictures as they are into APP and it works... All the other stacking programms are the same. Never heard about such an issue...
I use Pixinsight, I've been imaging the Wizzard Nebula over several weeks due to the weather in the UK. As a consequence, I have images from both sides of the meridian without rotating the camera.
In Pixinsight using either manual stacking, or the WPBB script the images stack perfectly with no issues whatsoever. I avoid moving the camera at any cost to help with the alignment of the subs.
Prior to Pixinsight I used DSS for stacking and it was the same. All stacking programs use the stars for alignment and rotate the subs to suit. Rotating the camera is a recipe for disaster unless you have an accurate rotator system or a lot of patience.
Any stacking program that tries to cater to astronomical images can handle rotated images just fine. The only stacking programs I know of that don't would be Photoshop and Zerene Stacker, both of which are not really suitable for astronomical images anyway. PixInsight, AstroPixelProcessor, Siril, ASTAP, DeepSpaceStacker and so on all handle them automatically. For vertically mirrored images (for example when mixing images from reflector and refractor scopes) might require setting extra options (using triangles instead of polygons when registering for example), but normal meridian flip doesn't need anything special with any of those programs.
I understand that everyone doesn't rotate images on meridian crossing. This means that they process images rotated 180 degrees, which I know is not a problem because the software resolves the images before stacking them. obvious. Even for dark frames it is not a problem because they are used first to calibration process. I will also try to do this way. Thanks for the replies.