Astro Pixel Processor

Oops… a sphere after integrating lights

Viewing 11 posts - 16 through 26 (of 26 total)
  • Author
    Posts
  • #15062

    Haverkamp
    Participant
    posts: 648

    What would be the minimum required overlap as a %-age of frame width/height?

    I would say, that APP needs about 10% of frame width/height for most cases but it strongly depends on several factors.

    – the amount of detected stars at the borders of the frames, the more stars detected, the less % it needs.

    – the pattern recognition engine creates patterns in the frame to be aligned at different scales and different areas of the frame. These patterns are then compared to patterns found in the reference, also at different scales and areas. The actual implementation of this can be a limiting factor as well. I will test this on @mauricetoet’s data.

    So depending on the data and the relative orientation of the reference and frame to be aligned, the percentages could actually be in the range of roughly 2% to even 25 %.

    If you are planning to create a mosaic, for best results, I would advise to have at least 15% overlap and preferably a bit more. The more stars that are detected, the higher the chance that registration will be perfect.

    @keesscherer, what % did you use in planning your 6 panel Virgo cluster mosaic?

    I will have a look at Maurice’s data later today, I’ll make an assessment of the amount of overlap for these 2 frames where registration fails and will report my findings. I hope this data helps me in reducing the required % of overlap for any dataset ?

    #15064

    Haverkamp
    Participant
    posts: 648

    “Too little overlap between the panels might cause the issue. “Hollandse zuinigheid”, I’ll send you all (6) panels.”

    Great, I will have a thorough look to see if we can improve this ?

    • 1 person likes this.
    #15077

    Haverkamp
    Participant
    posts: 648

    @mauricetoet, I am studying your data.

    First of all, I again notice an instability in the complex model, which causes it to run for quite some time. This is the complex model for

    – Multiple View, not”same camera and optics” with “dynamic distortion correction” on

    This is fixed, now.

    Secondly, I have lokated the two problem panels. I notice from the file name that one of these is integrated with drizzle, “_1.0_1.0_dr-sqr” :

    St-avg-9000.0s-WSC_1_3.0-x_1.0_1.0_dr-sqr-full-qua-add-sc_BWMV_nor-AA-RL-MBB5_2ndLNC_it3.fits

    The other panel is done with Lanczos 3, “_1.0_LZ3”

    St-avg-7200.0s-WSC_1_2.0-x_1.0_LZ3-ref-qua-add-sc_BWMV_nor-AA-RL-MBB5_1stLNC_it34.fits

    Maybe, it’s a good idea to create that panel with LZ3, it probably gives a better SNR,  Signal to Noise Ratio, I think.

    Anyway, i’ll now focus on why these two panels refuse to match properly ?

    #15081

    Haverkamp
    Participant
    posts: 648

    Okay, the amount of overlap between the 2 problem frames is only 7% of the height dimension. That’s pretty low.

    And if I try to register them to each other, it works fine if I choose

    St-avg-9000.0s-WSC_1_3.0-x_1.0_1.0_dr-sqr-full-qua-add-sc_BWMV_nor-AA-RL-MBB5_2ndLNC_it3.fits

    as the reference, but if I choose

    St-avg-7200.0s-WSC_1_2.0-x_1.0_LZ3-ref-qua-add-sc_BWMV_nor-AA-RL-MBB5_1stLNC_it34.fits

    as the reference it fails. So this is a problem in the pattern recognition engine which I’ll try to fix.

     

    #15088

    MauriceToet
    Participant
    posts: 56

    Maybe, it’s a good idea to create that panel with LZ3, it probably gives a better SNR,  Signal to Noise Ratio, I think.

    Yeah, you’re right. I was exploring to many settings at a time.

    So this is a problem in the pattern recognition engine which I’ll try to fix.

    It would be great if you can find a problem and fix it. 7% overlap is indeed pretty low though.

    #15128

    Haverkamp
    Participant
    posts: 648

    @mauricetoet,

    I am working on the registration engine.

    In the next version you can now select the scale on which pattern recognition is done.

    For regular (not mosaic) stacks, only scales of  1-5 are needed to get optimal registration.

    Internally, I had this fixed to scales of 1 to 8.

    For the mosaicing, it will be much more efficient to use smaller scales if you have panels that have little overlap. For your mosaic, you can use scales of 8 to 12.

    Simply said. A descriptor scale of 10, means the pattern is only 1/10th of the frame’s dimension. So this descriptor size would be needed if 2 frames to be aligned with each other only have 10% overlap.

    Your problem frame only had 7% overlap. For this to be registered robustly, you would need a scale of 12 or 13.

    Since I had fixed internally to only use scales of 1-8, this became a problem. You can now tweak this.

    If you are using scales higher than 8, use the pentagons for more speed 😉

    I am now working on the actual multiple view mosaic algorithm. The result is better but not yet perfect, so I am trying to see if I can improve more.

    #15141

    Haverkamp
    Participant
    posts: 648

    @mauricetoet,

    I am working on your data and I am testing a new algorithm. But, I clearly see some problems with the data, probably arising due to applying “dynamic distortion correction” already on the single panel integrations.

    There are 2  workflows, that will probably give better results. Can you try any of these 2 if you have spare time, or send me some of the calibrated files from each panel so I can test it myself and possibly use it for more optimal workflow topics?

    1) create the mosaic first using using only 1 single sub per panel and save the found distortion model, you need to use the

    calibrated projective registration model and

    turn on “same camera and optics”

    to be able to save the distortion model/camera profile. Then apply this camera profile to your data while integrating the panels. Then the mosaic integration can be done without distortion correction since all panels are properly corrected already.

    2) create the panels first without distortion correction (which could be possible I think with your data without big registration errors) and only use distortion correction when you integrate the mosaic. You need to turn of “same camera and optics” in this case while registering the mosaic.

    I know from testing on Yves mosaic data, that these 2 methods are to be preferred over the workflow that you used in this case.

    (If you send me all the data, I’ll create both workflows in 2 topics.)

    • 1 person likes this.
    #15144

    MauriceToet
    Participant
    posts: 56

    @bula Thanks again for all your effort. Your suggested strategy makes sense. Haven’t thought of that before.

    I’ll send you the data (all the raw files) as soon as I’m behind my computer (I’m currently typing on my phone). I’ll probably give it another try myself next weekend.

    #15192

    Haverkamp
    Participant
    posts: 648

    @mauricetoet,

    After extensive testing on your data, I have some conclusions now.

    First of all, the best workflow would be to make a camera profile using single subs of each panel. To do this we can register with:

    3) star analyis

    star count limit around 5000

    kappa above noise at 3

    4) register

    “same camera and optics” on

    “calibrated projective” registration model

    “mosaic” mode

    and save distortion model.

    During registration, you’ll be asked for focal length and pixel size, I used 500mm and 5 micron. You don’t need to be exact here. These are just used as starting points in the calculation. Then when finished, you can save this camera profile with a camera and objective/ota name.

    The next step is to create all 6 panels and use this camera profile for registration.

    “choose saved camera profile” witth dynamic distortion correction on selct the profile that you have created

    After creation of the panels, you can integrate the mosaic without using distortion correction. Or for further precision, use distortion correction, with

    “same camera and optics” off.

    This is the result I got. Not perfect, but near perfect now. Only 1 registration flaw on the extreme right where the center-right and bottom-right panels overlap.

    I’ll write down the exact stept for this workflow in the next couple of days ?

    I have 2 arguments why this 6-panel is actually very hard to get perfect.

    1) collimation problems, I noticed that the data was collected during several days. And collimation wasn’t constant over these days. Some panels have good stars in all 4 corners, but some have star shapes that are semi-circles instead of circles. This has a clear effect on the optical distortion pattern in your data, which isn’t constant, and also on the star lokation precision and the number of stars that are found in the corners particularly.

    2) Rather small overlap between the frames. The overlap areas are less than 10% of the panels width/height. This is rather small. I suggest to have at least 10% and preferably 15% overlap. This will help a lot in gettting perfect distortion correction and thus perfect registration. More overlap between the panels will also make the success of the mosaic less dependant on not constant collimation over all imaging sessions.

    To make APP more robust for mosaicing when the overlap is really small, I can improve more things in the registration engine. I’ll put these on the RFC ?

    I have also included 2 screenshots, one of a panel with a corner that has bad collimation. And the starmap of the entire panel, which shows  that the star detection is this corner is bad (lower-right), which has a clear effect on the registration precision.

    • 1 person likes this.
    #15195

    Haverkamp
    Participant
    posts: 648

    Added this to the RFC, should help mosaicing of frames with little overlap:

    “- For mosaicing, I need to provide option that pattern descriptors per scale are created along the borders instead of only squares spread over the entire image. By using rectangles instead of squares, the registration must become more robust with little star count at the borders. (Mabula, Maurice)”

     

    #15207

    MauriceToet
    Participant
    posts: 56

    Thank you, @bula. I’ll follow your suggestions and try to reproduce your result.

    I have 2 arguments why this 6-panel is actually very hard to get perfect.

    1) collimation problems, I noticed that the data was collected during several days. And collimation wasn’t constant over these days. Some panels have good stars in all 4 corners, but some have star shapes that are semi-circles instead of circles. This has a clear effect on the optical distortion pattern in your data, which isn’t constant, and also on the star lokation precision and the number of stars that are found in the corners particularly.

    2) Rather small overlap between the frames. The overlap areas are less than 10% of the panels width/height. This is rather small. I suggest to have at least 10% and preferably 15% overlap. This will help a lot in gettting perfect distortion correction and thus perfect registration. More overlap between the panels will also make the success of the mosaic less dependant on not constant collimation over all imaging sessions.

    Both are true. Collimation of the scope wasn’t perfect at that time. Focus comes very critical (@ f/2.8). When slightly off, collimation errors show up more pronounced. Especially when the frames don’t benefit from a before and after meridian “dither” (rotation of 180 degrees).

    Next time when preparing a mosaic image, I’ll take care in creating large enough overlaps.

    • 1 person likes this.
Viewing 11 posts - 16 through 26 (of 26 total)

You need to log in or to reply to this topic.