×

INDI Library v1.9.8 Released (29 Sep 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

How change ccd H-flip and V-vflip after meridian flip? and save in fit header?

  • Posts: 13
  • Thank you received: 0
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?
1 week 4 days ago #88315

Please Log in or Create an account to join the conversation.

  • Posts: 434
  • Thank you received: 156
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?
Remote observatory running Ubuntu 21.10 x64 with ScopeDome 2M, Skywatcher EQ8, TS 8" RC, Atik 383L+, ASI178MC, ASI120MM-S, SX Lodestar X2, SX USB wheel with OAG, ZWO EAF, Gemini SnapCap, USB_DewPoint, KomaHub
1 week 3 days ago #88364

Please Log in or Create an account to join the conversation.

  • Posts: 13
  • Thank you received: 0
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.
Last edit: 1 week 12 hours ago by Duccio.
1 week 12 hours ago #88493

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 45
Why are you even flipping images in first place? Stop doing that. All your problem stem from that.

It is like asking to help with painting a room while standing on your head while riding unicycle. Nobody will help you with it because nobody do it that way.
Last edit: 6 days 23 hours ago by nou.
6 days 23 hours ago #88504

Please Log in or Create an account to join the conversation.

  • Posts: 128
  • Thank you received: 11
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...
6 days 23 hours ago #88505

Please Log in or Create an account to join the conversation.

  • Posts: 74
  • Thank you received: 10
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.

Alan
Raspberry Pi4B,ASI120MM -S Usb3, ASI385MC, Atik 428CCD, Canon 600D, NEQ6, EQMod, EQ5, AstroEQ, EQMod, Equinox ED80, ASI533MC, RedCat 51 ASI 120MM Mini.
6 days 15 hours ago #88512

Please Log in or Create an account to join the conversation.

  • Posts: 434
  • Thank you received: 156

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.
Remote observatory running Ubuntu 21.10 x64 with ScopeDome 2M, Skywatcher EQ8, TS 8" RC, Atik 383L+, ASI178MC, ASI120MM-S, SX Lodestar X2, SX USB wheel with OAG, ZWO EAF, Gemini SnapCap, USB_DewPoint, KomaHub
6 days 14 hours ago #88514

Please Log in or Create an account to join the conversation.

  • Posts: 13
  • Thank you received: 0
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.
4 days 15 hours ago #88578

Please Log in or Create an account to join the conversation.

Time to create page: 1.026 seconds