Incredible!
Quick question - I noticed that Docker unsurprisingly loves all the RAM my imaging NUC can throw at it (micro-services schmicro-services!), woudl it make more sense for me to run the AstroImaging planner on my Mac and have it schlurp the files from my OTA NUC?
Alternatively I’m off to the store to get more RAM…
I am doing that, I have 3 imaging PC (very crappy hardware) and I do all the processing and analysis on a Mac. I keep all the files sync’ed locally using syncthing.
Cheers,
José
Cool! that’s awesome news. the less I have to use Windows the better, gimme Unix any day
Yeah, same here. I have three imaging PCs that are i3 w/ 8GB of RAM. It can run the planner/inspector, but I much prefer to have it centralized. I’m using Dropbox to sync them to my main machine. I run the planner on my main processing machine. It does run through a bit of RAM, but that’s mainly the virtualization layer. If you use docker stats while it’s running, you can see the cpu/RAM usage. I have set my memory limit to 8GB, which is overkill, but I’m also developing on the same machine, so am comfortable bumping that up. You can just as easily run it on 2 or 4GB of RAM. Although, if you’re crunching through a bunch of IMX455 frames, the more memory the better 
For data management, I’m also using airflow to coordinate local backups every 3 hours. Below is a view of the DAG that shows the dependencies in my archiving. I first pull all the new raw and calibration data from dropbox to my local external SSD. Then I push all that to my NAS. I should probably do another DAG that pushes things to S3 glacier or something, but haven’t gotten around to it. That would fit the 321 system of backing up data.
Gabe
Gabe, I continue to no write nothing because really happy on how the thing are evolving. Really impressed by your skill and results.
if can do something to help i’m happy, with the limit I wrote to you in PM.
All the best
Leonardo
Hi Gabe,
Awesome App!! I appreciate the critical thinking and hard work you have put into this.
I’ve installed version 0.3.0. Everything appears to be working for me except the tab Review Stored Targets is not populating. I am using Madratter’s Roboclip file. His Roboclip groups are by object i.e. galaxy, reflection nebula, open cluster, etc. I was wondering if that is the reason the Stored Targets shows nothing. I am seeing Acquired Data in the Target Review and Frame Inspector tabs, so the Planner is reading my image files.
Any thoughts on how to get the Stored Targets to populate?
Thanks for your kind comment Brian. Would you mind sending me your roboclip db file? I can see what’s going on.
Gabe
Thank you for taking a look at this. The db file wont upload to this forum post. Here is a link to the file: [Target List - Madratter's AstroImaging ](Target List - Madratter's AstroImaging.
Brian
Thanks for the link Brian. That’s quite an extensive list. I tested that file and found the same issue. After drilling down a bit into the issue, I think it is that the groups are named by object type. I’ll think about how best to handle this, since I know the naming will vary among different users.
The naming of the profile is this way to align the roboclip target with the subframes. The profile name contains the telescope/sensor, so relays info on what the image scale, etc. are. This allows me to match the profile to subframes. The issue which I’ve found is that I’ll image the same object at different focal lengths, e.g. NGC7023 with both long and short focal lengths. Pairing the data w/ the right profile avoids confusion about the progress of that target for different rigs.
Gabe
I just had an idea to rather use RA/DEC, focal length, chip and pixel size to merge the target and object in the roboclip database. I can work on this change in the coming weeks. This will allow a profile to have any name.
Gabe
Gabe - when you decide you no longer need it, can I please borrow your brain - it’s amazing!
Gabe, using the ra/dec values is a great idea. That should work with any Roboclip database.
Brian
Hi Gabe,
This is an amazing piece of work!
I myself have been playing a bit with astropy and astroplan in python to do a bit of astro-planning, but yours look slick and pulling in roboclip files is a great idea.
Something I am trying to crack is optimising my sequences of different filters especially when shooting large mosaics.
So lets say you have a 4x4 (16 panel) LRGB mosaic. I would like to optimise shooting my B’s say above 60deg altitude, my G’s above 45deg and my R’s above 30deg. The L’s should also be optimised in some way to shoot them as high as possible. Time to meridian transit should also be accounted for to minimise meridian flips during the session. Not an easy problem… 
So far I have built a scoring system to assign a value considering the set of rules discussed above to each frame’s colour channel, in 30min ‘slots’ during the session. This creates a massive array of scores and currently I must work through this manually to evaluate and pick what Im shooting when. This part of my process do need a lot of work.
Maybe this kind of optimisation will be a great addition to your planner program as well.
Thanks again for sharing the great piece of work, really sparked a lot of ideas.
Best Regards,
Jacques
I have a working version of the planner that matches the targets in the roboclip database, and the objects stored. I tested this with the Madratter’s Roboclip db file @Brian linked to, and it works pretty well.
Internally, what this does is match the distance in degrees between the target RA/Dec coordinates and the entries stored in the FITs headers. Then, I create a metric called frame overlap fraction, which related to the distance from the target center to the frame center, divided by half the vertical field of view. Specifically, it’s: 1 - distance / (fov_y / 2)
You can specify how close the object should be compared to the target with the Minimum Frame Overlap Fraction setting on the left side.
This version is live under the dev tag. To use it, you can do the following:
docker pull gshau/astroimaging-planner:dev
env.conf file to use the dev image rather than the latest. You need to make changes so that it reads APP_VERSION=dev (note, if you don’t see this entry in your file, you need to be working from v0.3.4.)run-app.sh or run-app.bat fileTo go back to the latest version, just change APP_VERSION=latest and run again the run-app file
Let me know if you encounter any issues!
Gabe,
I was able to get the dev version working and the Targets Table loads now! I am still playing around with all of the pages and options, but so far, it looks good.
Is there a way to limit the decimal places displayed for total time on each filter in the Targets table? It is reading out about 14 decimal places. Two places is enough for me.
I’ve been keeping an Excel spreadsheet tracking each one of my targets. Using your AstroImaging Planner, I identified at least two different sessions I failed to log in my spreadsheet (I have more time on targets than I thought).
Once I process my data, I move all the subs to a usb hard drive. Will this mess up the Targets Table, or will that target just drop off the table?
Thanks again for the app.
Hi guys,
i’m afraid i think i am less of a pro than the average member of this group!
i have downloaded docker, but not sure what to do with it.
and made tweaks in the env file and clicked on the batch file in the astroimaging planner folder …
the terminal box pops up for a couple of seconds and disappears with out anything else apparently happening…
is there a more blow by blow idiots guide to setup?
thanks
Hi Gabe, i just explained on group chat that i dont seem to be able to get AIP to work on my machine.
if it would be fast for you to jump on it via teamviewer etc and look under the bonnet than write an idiots guide then i’d be happy to oblige - also can we leave $contributions for assistance and for the work you’ve already done?
thanks
gavin
The rounding issue will be fixed in the next dev build. Currently, there’s no adjustments made in the internal db to the paths of files if you move them. The metadata - star metrics, total exposure, etc. is still there. However, you cannot use the 9-panel inspector since it loads the data when you click on a point in the scatter graph. I can look into making the fix for tracking files moving over time.
That’s great! I think all you would need to do is navigate to http://localhost:8050
mmm. i had missed that element, so was hopeful but when i tried it i just go a “cannot reach this page” error… 