My apologies, I hadn't found that information. I'll look at consolidating all of it - I have some X-T2 specific points as well.
My one line change was merged in for the INDI Library v1.9.5 release. I don't think there's anything else to be done in INDI - I wouldn't change the default or enforce the SDCard Delete due to the limited testing and the potential for Fuji to change the behaviour for future models.
It would be useful to document driver quirks / specific configuration requirements so that new users don't have to 're-invent the wheel' but where would be best for this? The KStars Handbook is the most user accessible place but doesn't contain any device documentation (correctly in my opinion). Upstream for the driver may be ideologically best which would be at github.com/gphoto/libgphoto2/tree/master/camlibs/fuji but then this is really hard for users to find and the content, style & maintenance is down to others, so maybe it should be at github.com/indilib/indi-3rdparty/tree/master/indi-gphoto ?
Maybe we could add a few links to INDI driver documentation in the 7.7 INDI Frequently Asked Questions section of the KStars Handbook? The trouble is that INDI driver documentation is non-existent for many of the drivers and depends entirely on the developer. I feel that this is one area that limits adoption of the whole INDI ecosystem for non-technical users. I don't know what the solution to that would look like - maybe more user guide / workflow style documentation for INDI drivers? This could be a large undertaking but maybe a format template and a few simple example cases would be a good start?
Thoughts / opinions?
I'm a Fuji kstars imager. Having to set SDCard to Delete is a long standing known limitation. In fact I patched the Indi Fuji implementation to allow saving of that setting in the config.
The other issues I've run into are: aborting a capture can leave the frame in the buffer - the only way to recover if it does is to stop the indi server and power cycle the camera; If the GFX 50SII uses the same autofocus technology as the smaller XTrans sensors you may have an offset region on your calibration frames that needs to be correctly handled when stacking. Siril can take care of this but I don't know about other stacking software.
Part 5 – Approach 4 – Format Wizard GUI
A separate GUI dialog that steps you through choices to build and return a Format string with questions and answers. Might feel a bit clunky for power users and/or a bit long winded for simple users.
So, I was going to add a Poll to the topic but the function doesn’t seem to work well for me so please add your ‘votes’ and comments in replies. Thanks in advance.
Part 4 – Approach 3 – Simplified Format GUI
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.
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.
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.
Note: This will be a multiple post introduction.
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.
Hi, I use a Fuji X-T2 with Kstars/Ekos/indi. The driver has some limitations but it does work. Driver configuration points:
Found it, I'd run the local commit without a user.name set.
Sorry for the noise.
I have little experience with git so this is probably due to my lack of knowledge.
I've forked the kstars repository on invent.kde.org.
When I try to push a change to my fork (via https), git prompts for username & password. I enter these and am authenticated but I receive an Audit failure message for Non-full name. Repeating with my full name for the username field (unsurprisingly) results in authentication failure.
user.name is set correctly to my full name in the local project .git config. There's no global/system git config overriding it and no git environment variables set.
Added a .ssh key and tried the push via ssh. Again authenticated OK but still get the same audit failure message.
What am I doing wrong? Github has never fought back like this!
Thanks for any enlightenment