Where does Observatory fit into my workflow?

[Lead_weight]

This is a question I've been debating a lot lately. I want to support native Mac applications as much as I can, and have owned Observatory since the beginning. I prefer them in every way over non-native apps that have been ported across platforms because of the ways they can take advantage of the operating system features and hardware.

Where I think Observatory fits for me is as a catalog for final processed images, and as a research tool for new images. So, this leaves a huge chunk of the application feature set out in the cold for me. Specifically the imaging processing parts which are unique to this native application. So I started to think, why is that?

For me, it seems in my light polluted skies, I take lots and lots of short exposures to mitigate light pollution. What this equates to is a few hundred images per object. The real-time ability of the application to process these images is severely hampered when processing large stacks, to the point that it does not become useful anymore as a real-time application. The second point I find is that as I get more serious into astrophotography my setup gets more complex. I now image with mono cameras, so I have multiple stacks per color channel, flats, darks, etc. The number of images I have, and types exceed the capabilities of the application, as I have no way to combine those color channels within the application. And truth be told, there are a number of non-realtime applications that dedicate some serious effort to workflows like this, and can provide more flexibility to arrive at a pleasing end result (at the expense of time) such as Astro Pixel Processor, PixInsight, etc.

So this application, given its current feature set works really well to catalog those final images. I love how, once place solved, the images get tagged with all the objects in them, and auto filter down to smart folders based on object type, telescope or equipment used, etc. This is a really great way to look at your object sets and pick new objects to observe that you maybe have not covered very well, or at all. Recent additions to the ease of plate solving really help to serve this function of cataloging, and was well worth the effort to add it. I could only see adding some type of equipment manager as a possible bonus feature so that you can easily tag your images with equipment used (similar to functionality used in Astrobin.com).

This brings me to the research part of looking for new objects to image. This software provides very robust access to huge data sets of possible objects to image. Which is really nice. Since my research of these objects is limited to my use case of capturing images with my astronomy equipment (and not scientific study), I find that it’s lacking some features that would help support this use case. Starting with an FOV calculator so that you can match your equipment profile with data that is available to the application and overlay it over an object to see which piece of equipment (telescope, camera, reducer, Barlow, etc.) can enhance the FOV to suit the best possible outcome for that object. Here’s a good example of that in practice (https://astronomy.tools/calculators/field_of_view/).

Another amazing app, that I find great for all that it can do in a small compact screen for the iPhone is Observer.pro (http://www.observer.pro/blog/2016/1/15/observer-pro-11-is-now-available-on-the-app-store). It shows the night sky, moon and sun, rise and set, object visibility during that time, etc. Functionality like this would go a long way to enhancing the viability of this program as a research tool for image or observation planning. I don’t know if the developer is readily developing that application. It seems he goes through long periods of inactivity. Maybe he’s willing to part with some of his assets to aid in an effort like this? Anyhow, it’s just a thought.

All this is to say, that I want Observatory to be successfully and when I judge it based on my personal use case, this is how I see it fitting in. Hopefully this post will spark some debate or thought one how to best serve the users of the program and their use cases. And I think this is just the start in aiding that use case, as there are many other ideas out there that could contribute to an application such as this. Polling your audience through a questionnaire might help direct some of the development, as I'm surly not the only voice here.

[heyjp]

I am a total newbie, just getting started with Observatory.  I have a bit of an opposite hopeful outlook.  I am not as much worried with cataloguing final images (although I certainly will keep finals referenced here) but I always put my finals in my general photo app (Apple Photos in my case) for sharing and using on the big screen TV I screen saver.

My big hope is managing the hundred and thousands of RAW images that I DO not want to clog up my Apple Photos with.  A  dedicated low overhead, out-of-the-main-stream place to keep those organized for processing or even integrating images of an object captured over many sessions across many years.

I am struggling a bit with the documentation to figure out the typical mapping of folders, files, albums, stacks etc into practical metaphors.  It would be good to find some best practices of how others map these relationships.  How do people organize their lights, darks, flats, prior to importing to Observatory?  Then how do they maintain their organization between sessions, ,locations, conditions and equipment?

Jim in Boulder

[Sander Berents]

This is an interesting topic. I hope more users will chime in, so we can get to a consensus about workflow recommendations. With enough feedback I may then be able to add it to Observatory's documentation, and optimize the application itself for that.

In my file system, I organize my imaging sessions in a YYYY/YYYYMMDD folder structure. I ignore the timezone, it's just where I am at that moment. I always put a YYYYMMDD.txt file in each YYYYMMDD folder for useful notes. I use Finder's batch renaming feature (renaming multiple files at once) to get the actual image files in a format like

"YYYYMMDD.<object id if any>.<filter name if any>.<image type unless ‘light'>.<exposure count if more than one>x<exposure duration in seconds>s<xbinning>x<ybinning><CCD temperature in Celcius>_<index number>.fits”

all lower case except for the filter name. For example "20121227.dark.120s1x1-15_001.fits" or "20041029.m76.Ha.4x1800s1x1-15_001.fits". I use that convention even for my stacked images as you can see in the second example. I group them in similarly named subfolders (same, except the "_<index number" part), unless they do not have an index number (e.g. stacked results).

I don't encode the location, telescope or camera type in the file names, but especially the latter two might be useful if you have lots of equipment. With all the indexing that Spotlight does for FITS and XISF files, encoding all that information in the file names is not strictly necessary, but my naming approach predates Observatory, and I find it useful anyway. Now that Observatory exists, Quick Look, Spotlight and Finder's "Get Info" are extremely useful for file system organization.

You can see some of my naming approach back in Observatory's default exporting templates.

Don't limit yourself to only a single large Observatory library. Instead,

• Create libraries for things you are interested in. A library for minor planets for example, one for variable stars, another one for exoplanets, etc.
• Create one library for final images. Managing the final images in Apple Photo is fine, but put them also in a dedicated Observatory library. That way you can add comments and additional files to each image (e.g. papers about the subject), tags, etc. Also plate solve them all, for the overlays, automatic tagging, astrometry, and it makes photometry easier.
• I also have a library that contains all my images. I use it mainly to sift through images for file system cleanup and find images that may contain objects I am interested in at that moment. It is more or less a reflection of the file system, but with the extra tags and some color labels. I have the images stacked in there, but I do that mainly for organizational/convenience purposes in this library, not for the processing itself. As Observatory evolves, I recreate this library every once in a while, to fully get the benefits of new features. I also use Quick Look and Spotlight extensively for all my FITS files.
• Use ad hoc libraries, just to quickly inspect or stack the results during and after an imaging session for example, or to see what to expect using Virtual Observatory. I don't typically save those libraries, unless I use it for processing or photometry of a specific subject. For those cases I often have images obtained through Virtual Observatory in there as well.
• Except for my large library, I typically rename the images inside the libraries to more friendly names (all at once). Observatory will show the original name as "id" in the inspector anyway.