Forum Replies Created
-
Posts
-
Brilliant. Really hadnt realised you just had to look 60 degrees in front or following the sun. That makes it pretty easy, get the sun’s position on ecliptic in RA/Dec, convert to ecliptic cooords, add 60 degrees and convert back to RA/Dec again. Sure I can find something in AstroPy to do most of that. I imagine that drops it nicely into the edge of the Zodiacal light.
Thanks again.
It was a nice, friendly and well organised conference. Some very interesting talks.
Shame its a bit expensive for amateurs to attend – but its not really aimed at us.
Watched for the 00:08 pass from here in Salisbury. A single 3rd mag satellite went through at about 0:08 but certainly nothing else brighter than 5th mag was seen for 3-4 mins either side.
Perhaps their shape means there will be passes when they are bright and other faint – a bit like iridium flares.
Had a look at the last two papers. It all looks pretty straightforward – though the devil will be in the detail as they themselves admit, care is needed to ensure the implementation is robust against residual defects, cosmic rays and artefacts. Would be fairly easy (though fiddly) to implement in something like Python – shame some of the commercial packages go for the simple solutions only – its not as if CPU and memory is expensive anymore.
It was surprisingly familiar as I saw similar methods presented at an SPIE conference in 2003 or 2005 (cannot check as work went “smart working” a year or two back and lots of conference proceedings got thrown out when we lost book shelves) where there was a session on dim source tracking techniques.
Will have a look at the other paper on Tuesday and report back.
I’m curious as to how you make a weight map. Are they looking at the darks, flats and defect maps or doing something more sophisticated? Drizzle normally works best though with large numbers of oversampled images doesnt it?
What does that do to the photometry? Doesnt drizzle interpolate values with a bicubic spline or something?
Thanks for that. I shall have a look at it. The appendices sound the interesting bit.
I have always felt people are careless with median stacking. Transparency changes can have a huge impact on the results – simply normalising the backgrounds isnt enough, normalisation of the signal received is necessary too if you want to do things thoroughly (so some sort of gain correction is necessary). I tend to avoid really long exposures and median stack images in sets of ~10 and then coadd all the resulting frames.
Thanks. Will give that a go when we get a clear night – though the forecast in Salisbury is cloudy for a most of the next 3 days.
Are they really ready for operations that fast that they are already ion driving? Thats a pretty quick shakedown.
So you give it an externally sourced template/reference to aim for? Isnt that dangerous?
Can understand running the process and getting an improved result and using what that processing generated as your template/reference for an iterative process.
But using imagery from some other source means the result is not led by the data itself.
I would imagine the impact of the noise varies depending upon how the wavelet transform is implemented in Registax. A large chunk of the image being replaced with a single value would certainly change the frequency spectrum and has reduced the total dynamic range within the image.
The pixels on the planet will still contain readout/sky noise, but that is a lot less obvious when on top of the brighter background provided by the planet.
My first inclination would be to wavelet first and apply any threshold afterward, but I’m probably over cautious.
