Great work @Michael Ring . The stitching also looks good. What method are you using? Here is my latest attempt in the South. PI: MosaicByCoorindates + PhotometricMosaic. After that a bit of stretching. [Arcsinh + HT on the stars] Six fields only.  |
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Wow, looks amazing!
I also used MosaicByCoorindates + PhotometricMosaic and failed miserably to start the 2nd row in the first pano. My data is only stf stretched and no blurX or anything applied.
I used GraXpert for the gradients, the tool took me only a little longer time to apply than abe but provided results similar to dbe, highly recommended!
Michael
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Some more analysis of the data I took in the -70 to -80 region After running SPCC and resampling to 10arcsec/pix, I ran MosaicByCoorindate and GradientMergeMosaic on the full 12 fields for GMM and a smaller sample of 9 field for PMM. Here are the results (stretched with STF) First GMM - much easier to implement than PMM, but leaves pretty obvious stitching effects in my data  and PMM  Completely baffled why the field edges are this way - I must have a parameter set wrong [any help?] but the seams are much better - stitched in dec strips first. I then applied BXT (to a cropped version of the linear image) and stretched with arcsinh stretch.  I don't think this is looking too bad.... (its a bit green) but it also illustrates the difficulty of reproducing both the Milky Way and the IFN like Chameleon III/CED 111.
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Progress update ... things are starting to happen! To date, 29 fields (2.5%) have been completed and an additional 39 have a volunteer imager. It's fantastic to see some early mosaics appearing as well. On completions, the southern hemisphere is outstripping the north 28 to 1 (here's looking at you, @Brian Boyle) Appreciating that it's currently summer for our northern friends, it would be great to get some input from people living at lower northern latitudes who still have dark nights. Ophiuchus, Serpens, Hercules, Draco and Ursa Minor are all ideally placed at the moment. You can always check out the fields that need input at Astrobin All Sky Survey field management tool 6x9 - Google Sheets. Please drop me a note if you have any questions about accessing the booking sheet.
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Thanks to a good suggestion from @Michael Ring, I've added sky quality (SQM) and integration time fields to the Google booking sheet. Please make sure to provide this information when submitting images as it will help with evaluating the SNR and image quality.
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Great idea to keep record of these parameters for documentational purposes! I also did some tests with @Brian Boyles data. I can confirm that our decision to skip ABE with first degree approximation was indeed correct. Applying ABE prior to stitching significantly degraded the glow of the Milky Way. However, I still don't have any idea on how to solve the gradient and color calibration issue completely. Maybe we should create a subgroup for image processing challenges, as I guess this will lead to some extensive discussions. If anyone is interested to collaborate in this, let me know. As of now, we still have two competing ways of stitching. I had great success with GradientMergeMosaic while Brian had a lot of success with PhotometricMosaic. We still have to decide on one final approach, I guess. CS Gerrit
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Hi Gerrit,
I think we are making good progress on our test lunation. Re:stitching… I am not sure which is best. If I were 30years younger, I might have a crack myself at writing the code to take the MosaicByCoordinates registered frames and merge them simultaneously…
PhotometricMosaic is good - but very tedious to use (since it only works on frame pairs). What we need is a good RCAstro routine: SeamXterminator??
Brian
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
+1 for creating a Astrobin Group to be able diverify the discussions in seperate threads a bit, this threads starts getting way to big. @Brian Boyle: AstrobinAllSkySurvey sounds nice as a name, what do you think? Michael
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
src/scripts/JohnMurphy/mosaic/src/lib/Gradient.js seems the right place for doing modifications to the Merge process. There seem to be functions to create a path for the joinRegion and one function to apply the changes:
/**
* This class is used to apply the scale and gradient to the target image
* @param {Overlap} overlap Represents the overlap region
* @param {JoinRegion} joinRegion
* @param {Boolean} isHorizontal If true, the join is horizontal (one image is above the other)
* @param {PhotometricMosaicData} data
* @param {Boolean} isTargetAfterRef True if target image is below or right of reference image
* @returns {ScaleAndGradientApplier}
*/
function ScaleAndGradientApplier(overlap, joinRegion, isHorizontal, data, isTargetAfterRef) {
Perhaps contacting john Murphy could make sense…
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Regarding the stitching, I came across this website: Montage - Image Mosaic Software for Astronomers (caltech.edu)As the name suggests, Montage is a set of programs for stitching together astronomical images into mosaics - it seems to be used professionally for this purpose. It's really designed for Linux/Unix systems and I ran into some issues compiling on my Windows machine. However, reading the documentation it seems to follow a similar methodology to the one I outlined earlier: - Use plate solve information to project frames into a universal coordinate system
- Identify portions of neighbouring frames that overlap and calculate the pixel-by-pixel differences in the overlap regions
- Fit the differences with a simple functional form (Montage uses a planar surface)
- Subtract half of the difference from each frame
- Save the corrected frames
So far, I've put together some code that takes the plate solve information (wcs.fits) file generated when an image is submitted to astrometry.net and uses this to perform step 1. I believe this is the same transformation that Astrobin uses for advanced plate solving - it includes identification of the coordinates of the image centre, the image rotation and scale and polynomial distortions up to 2nd order. I'm guessing that PI could generate similar plate solve information. With bad weather forecast for the rest of the week I should get a chance to try to implement steps 2-5 over the next few nights. I'll share what I learn!
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Wow James, that is really a lot of effort and knowledge you provide1 Thanks a lot for your work.
CS Gerrit
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
@James Tickner: Nice find, I happen to work on a Mac, so I am downloading right now. Having python integration is also not a bad thing... Michael
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Michael Ring:
@James Tickner: Nice find, I happen to work on a Mac, so I am downloading right now. Having python integration is also not a bad thing... Interested to hear how you get on. Trying to compile on Windows using msys (basically a port of Unix compilation tools), I bumped on the POSIX signal handling stuff which isn't compatible. But hopefully this might work better on a Mac. As you say, the Python port also looks very interesting and could provide a good environment for automating the whole chain. Unfortunately, I hitched my wagon to the Matlab train many years ago and Python is a bit of a mystery to me, much to the amusement of my younger colleagues!
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
@James Tickner I never got beyond Fortran77 and the Unix command line... Very happy if someone wants to set up a fresh discussion on the stitching. It is a good idea. This is what I think we have learned on all aspects of the Survey so far. 1. The observing and linear-processing pipeline (to WBPP autocropped output) appears to work well works well, and the SNR guidelines appear to reach the correct depth. 2. The Field Centres are fine 3. Post-WBPP is more of a challenge. ABE/DBE ruled out. But do we do SPCC/PCC/CC or resample before/after merging. [Almost certainly better to resample after sampling - but this makes the computational burden much much greater.]. This may best be answered by the answer to the next question.... 4) Stitching!!! MosaicByCoordinates does a good job with the astrometry, but both GradientMergeMosaic [seams, pinch points] and PhotometricMosaic [weird field boundaries, slow and only implementable pair-wise]. So if James can come up with something which gives us the best of both these worlds, that would be a huge service to the community [and valuable IP for James] Even if we can't work out the large-scale stitching issue, there is alway the alternative - and that is simply to publish the survey in large chunks [on 15 x 15 field centres created from a small mosaic of 6-9 individual fields on the current centres]. This would have the advantage of - at least visually - showing up the low surface brightness stuff [[IFN] without blowing out the Milky Way as they would mostly be in different fields. [Partially why I went for the polar cap region.] Not ideal, but still a useful resource. And a potential fallback.
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
I agree with most of Brians points so far. Just some thoughts about the list: 1. We have to settle on one singular approach for color calibration. In my opinion, it has to be either SPCC or PCC. CC is too subjective, since black and white point references are set manually, which can introduce a strong bias. I prefer SPCC due to better accuracy/data, but this is up to discussion I guess. The differences are not that big for large fields, but also the effort for SPCC is not much higher. 2. @Brian Boyle could you elaborate the sampling/resampling part of point 3 a bit more? Unfortunately, I don't really get what you mean, but maybe that is just a language issue with me. 3. As mentioned, I had some success with GradientMergeMosaic. When my exams are over (end of next week), I will have the time to do more extensive tests with it. If James makes the (very promising) alternative work for us, that would be great, but I think we can use GMM as a backup plan with some parameter fine-tuning. 4. Good point with preventing the Milky Way from blowing out. If we decide on a large panorama, this puts huge challenges for the stretching part. 5. Just as something to think about: What do we actually want to publish, or should we publish multiple versions? I think the color calibrated, stitched, denoised and stretched data would be obvious. But maybe another version without stars, so fainter nebula are better visible? Or something completely different? CS Gerrit
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
I agree with most of Brians points so far.
2. @Brian Boyle could you elaborate the sampling/resampling part of point 3 a bit more? Unfortunately, I don't really get what you mean, but maybe that is just a language issue with me.
CS Gerrit Hi Gerrit .... sorry I wasn't very clear (even in English) What I meant to say was that I resampled up to 10arsec/pix (from 6.3) before stitching, so all the images were 3 x smaller. It made the computations go a lot faster on my 5-yr old Mac. For the best results, we probably want to keep each panel at as high a spatial resolution as possible before stitching to get the very best results. But, that it also open for discussion. Brian
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Definitely +1 for keeping the raw data intact, it may be usefull for other scientific work or other things later, so we should not loose those hard earned pixels.
In Montage I know that you can define the final output density and I already used that feature and I think I read something similar in the docs of Photometric Mosaic but did not yet investigate deeper. I have nearly lost a quite long answer because of some issue with the forum software, I will either retype it in or will share what I could save with a screenshot later.
Michael
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
I decided to post a screenshot of my lost comment, so here you go: The 2nd part of course goes to @Brian Boyle, th moment I wanted to fix that the editor died on me. @Salvatore Iovene is there a way to save the text written from time to time? It is not the first time that I lost a rater long text in the editor...  |
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Thanks for the clarification, now I understand what you meant.
I also strongly opt for down scaling the data as late as possible.
PCC/SPCC rely on accurate star representations. Downsampling the data prior to this step will severely degrade color calibration. I guess the same applies to PhotometricMosaic, which could be quite a problem since it seems to need quite much computational power even with downsampled data…
CS Gerrit
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
I also agree that we do need SPCC (or PCC). I have not found any problems with SPCC but I have not gone too far from the galactic plane [a bit difficult right now]. I find I get better results with SPCC prior to stitching rather than after - but i could be convinced otherwise.
Since the fog has rolled in again, I am now looking at other mosaics I have done to see if I can regenerate linear data as per the pipeline for a few more fields. Most of my mosaics done previously have a lot more integration (factor 2-3) but I suppose that is not a bad thing.
CS Brian
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Color calibration of any kind should be applied prior to stitching, in my opinion.
Atmospheric conditions can and will change even for a single location between different panels, let alone different panels taken from other countries and equipment. This makes it necessary to compute color calibration parameters for every single field.
One thing we should keep in mind when using SPCC is that it needs camera/filter data. This is something we should either manage with the fits header of the integrations or with the field table. I guess metadata in the fits header will be better for this purpose since it makes plate solving and other processes easier.
CS Gerrit
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
@Brian Boyle When you work on your old data please consider setting the rotation to 0° and the Dimensions according to (for example) a 15x15 arcmin field in MosaicByCoordinates, this way we will get reuseable data that is properly aligned and that we can at some point consider as finished data.
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
Michael Ring:
@Brian Boyle When you work on your old data please consider setting the rotation to 0° and the Dimensions according to (for example) a 15x15 arcmin field in MosaicByCoordinates, this way we will get reuseable data that is properly aligned and that we can at some point consider as finished data. Hi Michael, Yes indeed. I am not sure how many 9 x 6 degs fields I will get, but it should be about 8-10. It will just take some time.... Brian
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
A bit more on the mosaicing... After many many failures, I have come to the view that my existing data on the Scorpius region is not fit for our purpose. The best PI stiching routine [PhotometricMosaic ] does not handle fields at different X,Y orientations well at all. My Scorpius region mosaic looks like it has mosaiced by a racoon on meth, rather than a Scandanavian architet. PM is also really tedious to use, doing only one pair of merges at a time. Note this also an issue for use as we get to really large fields, or close to the poles. Thanks to @Michael Ring I tried to put together four of his Ophiucus fields using PM and GM First GM  And now PM  I can still see some stitching here but it is In short, GM really only works for single strips, whereas PM appear to work better for multiple strips in both RA and Dec, but putting it together, pair by pair, strip by strip is tedious. @Michael Ring I used your fields in NoGradient - I hope this was right.
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
@Brian Boyle The NoGradient Data has already had GraXterminator applied, for me the end result looks more uniform but the documentation says that this is not necessary so I may be wrong. Did you manually select the position of the seam between two fields on my data? It helps to get smooth transitions when you make sure that there is no bright star at the seam. PM has nice tools to make the gradient between two fields as smooth as possible. I am working on a similar complex dataset as yours that I received from Todd, hope that I can give you some hints on how to best create the pano when the data is not properly aligned. One thing I can say is that cutting your data into pieces actually helps. Michael
|
You cannot like this item. Reason: "ANONYMOUS".
You cannot remove your like from this item.
Editing a post is only allowed within 24 hours after creating it.
You cannot Like this post because the topic is closed.
Copy the URL below to share a direct link to this post.
This post cannot be edited using the classic forums editor.
To edit this post, please enable the "New forums experience" in your settings.
