Part 1 - Background
Hi all. I’ve been working on a long term feature request that has been stuck within the development effort for a while. This is the ability to flexibly choose the filename and destination directory of your images within the Capture module. This will allow you use any of these items of information (or tags), along with free text, in the file naming:
• Target Name – eg. M42
• Exposure Time – eg. 0.001 (1/1000th sec)
• Capture Time Stamp – eg. 2022-07-11T01-53-22 (yyyy-MM-ddThh-mm-ss)
• Frame Type – eg. Light, Dark, Bias, etc
• Filter Name – eg. H-Alpha
• File Name of the sequence .esq file
• Relative to the sequence .esq file, the directory name at any path level above – eg. if the .esq file is stored at /home/pi/captures you could select any of: “home”, “pi”,or “captures”
• Relative to the sequence .esq file, the path name at any level above – eg. if the .esq file is stored at /home/pi/captures you could select any of: “/home/”, “/home/pi/” ,or “/home/pi/captures/”
• A sequential number with a defined number of digits – eg. 001, 002, etc, or 00001, 00002, etc, and so on.
All of the above is already defined and implemented by the prior work of @kchoi.
The task I’m left with is how to implement this in the GUI. I can think of a few approaches and would like you opinions and comments as to which way to proceed…
Note that all the following are just ideas, elements could be mixed and matched, and both the free text typing of a Format string and the ‘legacy default mode’ described in Approach 1 could be available for any choice.
Part 2 – Approach 1 – Simplest GUI, hardest work for (some of) the user(s)
This approach would be based on the new feature only being of interest to the most technical users. For casual users who may not want to use the new feature, almost nothing would change.
Those who image with narrow band filters over multiple sessions and make full use of the Scheduler module would potentially benefit most from flexible naming but may also be accepting of a ‘lower level’ interface to take advantage of it.
For this approach the GUI changes very little – the Directory & Prefix textboxes change name to Format & Target, and the Postfix tick boxes disappear. A new tick box could be added that sets the filename format to ‘legacy mode’ – ie. you get the current default behaviour of just using sub-directories for the Frame Types, and a filename of Target Name and a numerical suffix.
The tooltip for the Format textbox displays the information from my first post above in more detail.
To use any of the new feature tags the user has to type them in the Format textbox themselves.
Part 3 – Approach 2 – Completely detailed Format GUI
This approach assumes the new feature is desirable by all users and it’s worth extra GUI complexity to expose it in it’s full glory. To be clear, as multiple levels of path and digits in the sequence are supported, there are 35 usable tags available. Due to this complexity, a whole new dialog would be required. I’d see this as using a scrolling list of tags or ‘sea of tick boxes’ to build the format preview that is returned to the Format textbox when complete.
This approach tries to compromise between the extremes of simple & complex. A pop-out dialog that gives the tags as button and, for the tags that take a level argument, a spin box. Stays on top of the Capture module window when open and live updates the Format text box as tags are clicked.
I like Part 3, Approach 2 as its similar to what Excel uses for formats and a lot of users will be familiar with this way of defining formats. All that is missing is a box that shows the format string that has been built and and an example of what the filename would look like in real life.
At the moment there is also a difference in the way Scheduler & Capture save images. Scheduler will create a subdirectory with Object name and store under that eg. M_42/Light/*.fits whereas Capture ignores the Object name and creates from Light folder downwards. So would be good if Scheduler and Capture behaved in same manner.
Celestron Astromaster 130 on HEQ5 Pro mount, ZWO ASI224mc, 30mm guidescope with ASI120mm mini. All managed using Kstars/Ekos on RPi with Astroberry build.
Some of these are not really an issue with the current system.
I name my images with the following format object_b1g1T-15_10m_H, and the software appends Light/dark/flat and sequence number.
I don't really need the light/dark/flat to be appended and I have to remove it later as I name frames dark_b1g1T-15_10m etc.
So, it would be useful if I had some way of not appending the frame type and I would be mostly happy.
I can see that optionally having the date and/or time could be useful under some circumstances.
Losmandy G11 with Gemini 2 controller
QSI 583/683 monochrome cameras with filter wheel
Starlight Xpress Lodestar X2 guide camera
Microtouch Focuser controlled using Arduino UNO emulating Feathertouch controller
Raspberry Pi 2GB with Raspberry Pi OS 64bit Bullseye
+1 on the 'basic level option':
I have the date/target information in the main file path, and do not use anything else except the automatic Light|Filter|Dark subdirectory separation. I'd really appreciate that to stay available like that and store it as default....
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
I'm also with option 1. All the other "helper GUI" options will be almost as daunting as the "raw text" approach for the casual user. I like the idea to keep the legacy mode for casual users and a raw text option for users that will need a more complex naming structure. The raw text has an additional advantage: you can easily cut & paste format specifications, so you can post them on forums or share it with your colleagues. Using this raw specification, a live sample text with the path produced with the current format, will be welcomed,
My response may be a bit weird/long winded as it is to do with what may be a common user system. I am associated with Keele Uni Obsy, (38 yrs and sliding by) and its 24in reflector. The CCD camera (its had several) has been used for BVRI photometry (varaible stars/exoplanets) as well as simple imaging. In the future we may have spectrograph(s), polarising filters, "StarAnalyser" grating filters, and probably even more outlandish things.
A straight text input would be most flexible, but would lead to chaos as different observers adopted different standards. So I would ask for a huge range of choices, but tightly constrained at the same time so as to have a consistent naming scheme. "Any name you want so long as elements are in this order consistently".
So I guess I am in favour of the most complete gui, but handled in strict order, perhaps grouped by function, maybe highlighted by colour (pink is basic important, light green a bit less, light blue is esoteric), so that the most common wants are at the top (time, filter, exposure, dark/flat object, etc), and less common ones like wavelength range, grating/angle, slit width, polarisation, etc., are grouped below, and can be defaulted to 'off'.
I am not yet into extensive Kstars/Ekos mangling, but will be as I assemble an OnStep fork to handle the 24in and its peculiar setup.
Best Regards, James Albinson
Might suggest that the tags appear in a list builder dialog of some form so the user can see what tags they have added, and it can give the option to order the tags as well. This example isn't very representative of KStars, but I think you get the idea