Discussion idea - giving StarTools stdev data from stack?
Re: Discussion idea - giving StarTools stdev data from stack
Ooh, yeah, Ivo, those are some good ideas. I'll see where I can run with them!
In the meantime, though, I've written up a little script that will take already calibrated/registered images and spits out a standard deviation image. It's here - https://dl.dropboxusercontent.com/u/188 ... ssStdev.py - because you can't attach .py files in this forum. Note that I do clear out my dropbox every few days, so that's more of a temporary host until I release my full stacker.
You can create pre-calibrated/registered in DSS by going to "Advanced Parameters", "Intermediate Files", "Create a registered/calibrated file for each light frame". It spits out a bunch of *.reg.tif files alongside your light frames - and they have to be tiff, because my little script can't handle .fits, heh. Also, they have to be single-channel.
Next, you need to have the prerequisites to run the script, since I don't have access to a linux machine to make a prebuilt right now. It theoretically should just be
sudo apt-get install python3 python3-imaging
Tell me if you have any issues running the script after that. (For those not on ubuntu-derivatives, look for python3.4 and the python "Pillow" library for python 3.4)
Actually running it is like so:
python3 /path/to/dssStdev.py /path/to/images/*.reg.tiff
I'm still working on my stacker, but I figured I'd write something that's an alternative to my (probably buggy and unreliable) upcoming stacker.
But actually: Looking at the results of DSS and mine, it appears that mine is actually more accurate than DSS. Basically, the stdev of DSS's alignment has very very slight doughnut-ing, and sometimes a horizontal bar across the center of the star. I've found that this indicates that the star shifted a bit, for example, if the star is shifting up and down, you will get a horizontal dark bar where the brightness was relatively constant, and bright upper and lower parts where the brightness changed a lot. I haven't noticed this with my images, possibly because of what Amaranthus said - DSS might use less stars, where I'm going full-out and calculating the least-squares transformation best fit for all stars I can find.
Another related point, just for thought: Lets say there's a strong gradient in an image. If the registration is just barely off, and the gradient shifts slightly, then the stdev will become much, much higher than it should be, due to in one frame the pixel takes a high part of the gradient, and another frame it takes a low part. That might cause problems, I don't know.
In the meantime, though, I've written up a little script that will take already calibrated/registered images and spits out a standard deviation image. It's here - https://dl.dropboxusercontent.com/u/188 ... ssStdev.py - because you can't attach .py files in this forum. Note that I do clear out my dropbox every few days, so that's more of a temporary host until I release my full stacker.
You can create pre-calibrated/registered in DSS by going to "Advanced Parameters", "Intermediate Files", "Create a registered/calibrated file for each light frame". It spits out a bunch of *.reg.tif files alongside your light frames - and they have to be tiff, because my little script can't handle .fits, heh. Also, they have to be single-channel.
Next, you need to have the prerequisites to run the script, since I don't have access to a linux machine to make a prebuilt right now. It theoretically should just be
sudo apt-get install python3 python3-imaging
Tell me if you have any issues running the script after that. (For those not on ubuntu-derivatives, look for python3.4 and the python "Pillow" library for python 3.4)
Actually running it is like so:
python3 /path/to/dssStdev.py /path/to/images/*.reg.tiff
I'm still working on my stacker, but I figured I'd write something that's an alternative to my (probably buggy and unreliable) upcoming stacker.
But actually: Looking at the results of DSS and mine, it appears that mine is actually more accurate than DSS. Basically, the stdev of DSS's alignment has very very slight doughnut-ing, and sometimes a horizontal bar across the center of the star. I've found that this indicates that the star shifted a bit, for example, if the star is shifting up and down, you will get a horizontal dark bar where the brightness was relatively constant, and bright upper and lower parts where the brightness changed a lot. I haven't noticed this with my images, possibly because of what Amaranthus said - DSS might use less stars, where I'm going full-out and calculating the least-squares transformation best fit for all stars I can find.
Another related point, just for thought: Lets say there's a strong gradient in an image. If the registration is just barely off, and the gradient shifts slightly, then the stdev will become much, much higher than it should be, due to in one frame the pixel takes a high part of the gradient, and another frame it takes a low part. That might cause problems, I don't know.
Re: Discussion idea - giving StarTools stdev data from stack
Man oh man, put Ivo and khyperia in the US Congress, you both can show them how to get things done!!!!!!
Che
Che
Re: Discussion idea - giving StarTools stdev data from stack
You're on fire!
Will check it out as soon as I can free up some time (things are a bit crazy here).
Will check it out as soon as I can free up some time (things are a bit crazy here).
Cheman wrote:Man oh man, put Ivo and khyperia in the US Congress, you both can show them how to get things done!!!!!!
Che
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
Re: Discussion idea - giving StarTools stdev data from stack
Okay. After over a week of bashing my head in trying to solve the problem, I gave up and I'm just going to be using http://en.wikipedia.org/wiki/Iterative_closest_point which means images need to be *generally* lined up upon input. Say, more than 200 pixel offset or 30 degrees might not work too well (those bounds are complete guesses on my part, though, might be much more/less than that).
I'm using exactly (min(length(numStarsFoundInReference), length(numStarsInImage)) / 2) stars to do the calibration. I'll probably fiddle with that and make the ICP take less points, and the final transform calculation take more. There's also a 50-brightest-stars threshhold to make it not take too terribly long to calculate (50 stars is a few seconds per image)
On the bright side, though, I'm successfully registering really, really horribly low quality images from back when I had no idea what I was doing, that DSS actually was unable to stack - and registering them pretty spot-on, too!
I'll be finalizing and cleaning up the code in the next day or two, then I'll be ready for an alpha release!... maybe. Maybe not. We'll see
I'm using exactly (min(length(numStarsFoundInReference), length(numStarsInImage)) / 2) stars to do the calibration. I'll probably fiddle with that and make the ICP take less points, and the final transform calculation take more. There's also a 50-brightest-stars threshhold to make it not take too terribly long to calculate (50 stars is a few seconds per image)
On the bright side, though, I'm successfully registering really, really horribly low quality images from back when I had no idea what I was doing, that DSS actually was unable to stack - and registering them pretty spot-on, too!
I'll be finalizing and cleaning up the code in the next day or two, then I'll be ready for an alpha release!... maybe. Maybe not. We'll see
Re: Discussion idea - giving StarTools stdev data from stack
+1Cheman wrote:AWESOME
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
Re: Discussion idea - giving StarTools stdev data from stack
Well, I'm nervously putting out the first alpha. It's attached as a zip.
Please open and read the comments of Astropress.py, it lists dependencies required to run and important notes to keep in mind when using it.
Usage should be as simple as:
python3 Astropress.py --out output.fits --outstdev outputStdev.fits inputImages/*.fits
Hopefully it doesn't break too terribly bad... (I haven't even tested it on linux or mac )
Please open and read the comments of Astropress.py, it lists dependencies required to run and important notes to keep in mind when using it.
Usage should be as simple as:
python3 Astropress.py --out output.fits --outstdev outputStdev.fits inputImages/*.fits
Hopefully it doesn't break too terribly bad... (I haven't even tested it on linux or mac )
- Attachments
-
- Astropress.zip
- (6.94 KiB) Downloaded 440 times
Re: Discussion idea - giving StarTools stdev data from stack
I will try to test this evening, if all goes as planned.
Che
Che
Re: Discussion idea - giving StarTools stdev data from stack
Excuse my ignorance, but I dont know how to proceed. Python is installed on my comp but dont know what to do next. Would be happy to test with my images if you can guide me thru. Treat me as a newborn baby here
Che
Che
Re: Discussion idea - giving StarTools stdev data from stack
Okay, yeah, perhaps it is a bit obscure on what to do.Cheman wrote:Excuse my ignorance, but I dont know how to proceed. Python is installed on my comp but dont know what to do next. Would be happy to test with my images if you can guide me thru. Treat me as a newborn baby here
Che
First off, you need to have a couple python packages installed, not just python itself.
If you're on windows, this means going here - http://www.scipy.org/install.html, going down to "Individual binary and source packages", clicking on numpy, 1.8.1 folder, then downloading/running "numpy-1.8.1-win32-superpack-python3.4.exe" (make sure it's ___-python3.4.exe, not another python version). Do the same thing for "scipy", version 0.14.0. Then open up command prompt and type in "easy_install Pillow". That should be it. Alternatively, you can download Anaconda http://continuum.io/downloads (make sure you click on "I want python 3.4"), which I *think* has all three packages pre-installed in the base install, although I haven't tested that.
Linux is an easier story, usually those three things are already provided in packages. They're usually named "python3-numpy", "python3-scipy", and "python3-pillow" or something of the sort.
In addition, if you want support for .fits files, you need to get a copy of cfitsio.dll/so, depending on your platform. Windows precompiled binaries are available here http://heasarc.gsfc.nasa.gov/fitsio/fitsio.html (Microsoft Visual C++ DLL), extract cfitsio.dll and put it alongside the .py files. Linux is, again, an easier story, there's probably a package named cfitsio or fitsio or something that you can just install.
I know this whole setup is a huuuge pain, and I really wish it didn't have to be so difficult, but scipy/numpy are only available on Python, which cannot be compiled into a nice standalone executable. I've been looking for alternatives, and so far I haven't had any luck (I've actually re-written a fair chunk of it in C++, but it's in general a worse product, since I don't know how to implement a lot of the things that were already implemented in scipy/numpy, for example, multivariate function optimization for 2d gaussian fitting)
Anywho, once you've got all the prerequisites installed, now it's time to run the stupid thing. Unfortunately there's no GUI yet, so open up a command prompt/terminal/whatnot, `cd` to the directory that you placed the .py files, and run the following (replacing the filename arguments as required)
python3 Astropress.py --out path/to/output.fits --outstdev path/to/outputStandardDeviation.fits path/to/images/*.fits
(16 bit greyscale .tiff files are also supported - color images are not)
The --outstdev parameter is currently pretty pointless, as StarTools doesn't have a public version that you can input standard deviation into, but that's the original topic of this thread until I utterly derailed it with my stacking program (you can just omit the --outstdev and filename parameter if you don't want it to pop out of the program)
I'll see if I can continue working on the C++ version so it's as easy as just getting a single .exe, doubleclicking on it, getting some open/save file dialogs, and you're done. Until now, though, this python madness will have to do.
Edit: Hold up, I just spent all of today bashing through C++, and I'm ready to release that instead of the Python version. There's some differences - mainly, not having to install a billion other python-related things, haha - all it needs is cfitsio.so/dll, everything else is statically linked. The algorithms are way different, too (due to constraints on what was available to me), so it may still be useful to use the python version and compare. Also, only .fits files are supported on the C++ version, haha. Final difference is it's about 5x faster ... I'll upload some prebuilt binaries when I get home and have the time to do so, as well as upload it to github if you want to build it yourself.