Hi,
I would like to see a few more options for suffixes that get appended to image file names in Ekos on the Camera tab. Currently it only allows "Filter", "Duration" and "TS".
It would be good to have a few more here, for example:
- ISO
- exposure/image number (counter since beginning of plan)
- camera temperature (especially useful for darks)
Right, this was brought up before. A better method is to use placeholders like
%TR%_%TS%_%FW%_%TT% and each is expanded to the corresponding value. TR ==> Target, TS ==> Timestamp and so forth. But that would take quite a bit of work and tests against possible regressions.
The original plan was to use the same parameters as RawTherapee. But it might not be practical to have this in the capture module. A separate configuration would probably be cleaner. And yes, regressions, aaagh. We should also decide whether path separators in target names should be considered part of the name or the path...
yes, I was thinking about placeholders as well. That might be better in the long term as it would also allow you to choose the order of info in the file name.
but just adding a few more in the same way as the 3 existing ones sounds a lot easier and less risky.
Maybe to reduced interface clutter and to respect the workflow it might be an idea to have a “daytime” or “darkroom” or “file management’’ tab in Ekos which is only concerned with managing your data/files, we could start with image files but then even add things like config files, telescope and eyepiece library etc.
Then whatever code is developed can focus on pre-pre-processing Steps like bulk renaming based on FITS variables, adding meta data, maybe a simple light table to sort and remove bad exposures and in my dreams “add this region to the ekos scheduler for tomorrow because I just realised I took 18 subs of a cloud” button
I think Ekos will try to remain on the observatory control side of things. However, there indeed should be a module dedicated to storage management, at least for a quick check of frames, but always oriented towards managing the capture part and not the post-processing part. Determining that some targets would require more (or less) exposure time from statistics for instance, or dumping frames to a remote storage, or simply editing and running the script currently located in the capture tab for every exposure.
Agree 100% I was thinking my first task will be to write a script to go through a file system tree and find every FITzs file, get the info and build a .esq file for every combination of Dark and Bias I need to generate/maintain for example.
The house keeping of managing data is probably one of the greatest requirements for ‘’operational control”, otherwise why are we doing all the other things? (We all know it’s actually to play with toys, but we need to convince our suffering friends and family it’s for the greater good