https://bugs.kde.org/show_bug.cgi?id=398757
Bug ID: 398757
Summary: Scheduler target name not taken into account by
Capture module
Product: kstars
Version: git
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: mutla...@ikarustech.com
Reporter: eric.dejouha...@gmail.com
Target Milestone: ---
When Scheduler configures Capture, it sets the target name as part of the
folder to which to store captured frames. Following the D-Bus rework, target
name is not part of that path.
Reason is that the method setting the target name was replaced by a property,
and Scheduler code requires update to accommodate that.
However, this situation could be an opportunity to rewrite that feature, which
is scattered over many places in capture.cpp.
The location where Capture stores frames is given by the concatenation of:
- Local directory,
- Directory postfix, itself a concatenation of:
-- Target name, if set,
-- Frame type,
-- Filter name, if any is used, and if frame is light or flat.
The file name under which Capture stores frames is given by the concatenation
of:
- Explicit prefix, if set,
- Frame type,
- Filter name, if required, if any is used, and if frame is light or flat,
- Exposure duration, if required, as integer if exposure has no fractional
part, or decimal if it has,
- Timestamp, if required,
- Integer index.
I observe that Capture UI indicates "Target" as default value of the prefix, as
a watermark proposal. But there is no code managing that hint, and prefix never
equals the target name. Target name is only used when set programmatically, and
only in the folder path.
All this is makes code complex, and creates a discrepancy between two use
cases:
- When used alone, Capture does not insert any object name as target name.
--
"<local>/<frame>/<filter>/<prefix>_<frame>_<filter?>_<exposure?>_<timestamp?>_<index>.fits".
- When used with the Scheduler, Capture inserts the name of the object that is
the target of the Scheduler's observation job.
--
"<local>/<target>/<frame>/<filter>/<prefix>_<frame>_<filter?>_<exposure?>_<timestamp?>_<index>.fits".
There are few possibilities:
- Make Capture fetch the target name from the last track request in KStars (but
that may mean finding an object from RA/DEC? EmptySky?)
- Add an explicit field (but that means a sequence can't be generic to multiple
targets)
This could also be a good opportunity to create a storage module, which would
centralize and organize frames. We could imagine a separate tab in Ekos, with
its own D-Bus interface, and showing the contents of the disk and allowing
quick access to FITS files and headers (currently, checking the results of a
night requires opening single files in FITSViewer). That module could then be
extended with features to manipulate images, even make use of plugins,
eventually jupyter notebooks or social features. But let's not get carried
away.
--
You are receiving this mail because:
You are watching all bug changes.
