Add Bandwidth field to filter slot data

[xthestreams]

Is your feature request related to a problem? Please describe. I would like to add (or work with someone to help me add) fields into the Filter class a feature for bandwidth, focus offset and exposure-time weighting that would be used to simplify and automate more intelligent exposures and automation.

Describe the solution you'd like I am working on an extension to the camera module to enable the creation of "ideal" exposure times based on the ideas in SGP and here; https://www.cloudynights.com/topic/573886-sub-exposure-tables-for-asi-1600-and-maybe-qhy163/

The intention is for a "push here dummy" capability for those starting out in AP who don't even know where to begin or the science behind making the decisions.

To do that effectively ideally the bandwidth of each filter would be stored against each slot enabling the calculations to be done automatically assuming some kind of "autopilot" mode is enabled.

Furthermore a "weighting" number against each would allow for an exposure offset either absolutely relative for each filter. If I had my "dream" we would be able to create a database of filters online that people could download which might also incorporate focus offsets too where not par focal.

MaximDL offers a similar feature.

Describe alternatives you've considered Keeping it all in my head. ;-)

Additional context Add any other context or screenshots about the feature request here.

[knro]

I think this does not exactly belong at the INDI driver level, it probably belong to clients. By bandwidth, you mean the bandpass in angstroms or something else?

[xthestreams]

It's a great question - I don't have an answer, but I also have questions - some of this was the result of me not realising that some of this is already stored in the KStars client - but I'll write out my logic below and see if that helps.

I think we can close this "feature request" but I personally feel as though it's digging into a broader question about data models.

Where do I define and manage filters and the related meta data eg: offsets, flat field exposure weightings, etc (the same is true of anything that's subject to physical change at the device location eg: scopes, guide scopes, lenses that would form an instantiation of "an image train".

The problem in my mind (there are a lot of problems in my mind!) is the data model for these objects. For example;

1). Lets say Alice runs a observatory - she has an ASI EFW 7 position filter wheel connected to a Raspberry Pi - not uncommon

2). Alice puts an LRGBHSO filter set in.

3). Alice locally runs Kstars client on the Raspberry Pi to check it all before going home. She sets the EFW through the control panel, it offers to allowing her to name each filter - these are stored on the device SERVER (config.xml file) - but from what I can see, the names + slots only - no additional information is stored on the device server.

4). Alice also uses the KStars client to create/refine entries for that filter wheel in the Configure Equipment section (which DOES include offsets etc). (or is that in EKOS, it's hard to tell where one stops and the other stars).

The rest is stored in the RPi Kstars client.

5). Alice goes home to image using her Mac client, she CAN discover teh names in teh filter wheels, but that's all - none of teh invariant technical information about the filters. So she renters that into her Mac client.

Now Alice has information in two places - which is the authoritative version? The answer is, provided nothing changes, who cares?

5). Now Bob comes along, connecting to equipment in Alice's observatory. His client on yet another computer - all that information is lost/needs to be recreated. He either needs to get some of the information from Alice somehow.

That's not too bad, maybe each client uses the same items slightly differently - but now the names of the filters are in three places, all with customisation of things like offsets etc.

6). Alice decides that the 7nm ZWO HII filter needs to be changed out to an Astrodon 3nm HII - in the filter wheel section does she change the name for that slot? let's say she does. "HII3nm"

7). Now the client has a slot that has changed - the good news is that every client pick sup on that change and see s new name, in the same slot.

8). At no point does the device manager trigger that the image train at the observatory has changed, but let's say Alice knows it's changed, she has to update both her clients.

What does she do with the information about the old filter?

How does she share the fact that it's changed with Bob?

Let's say she takes that old filter and moves it into a different device in the same observatory - what does she do with that information? Can she uniquely identify that particular filter if she wants to go back and re-use it later?

Essentially what I am suggesting is that any device should be able to tell me all I need to know about it - bandwidth, offsets, ideally it's transmission curve if I am doing science, manufacturer - all that stuff because as a client, I don't and CAN'T know it without asking someone - and rather than ask a person I should ask the device driver - in the same way my ZWO camera tells me its model, pixel size and resolution.

Again, no answers, lots of questions - this is big picture stuff that isn't close to the original design goals for INDI I am sure. Coming from a place of wanting to get the INDIHUB remote observatory model working really well and also from having two mounts and four OTAs that I move gear between a few times a year and I find that I am keeping information about those things on paper where it could be in a system somewhere and usually getting it wrong when I move things around.

If we could tap into a "device", "equipment library" server we could leverage what I know from work I've already done into another setting - thinking that maybe UUIDs could enable the tracking of what's getting used where and enable information about that thing to be defined and tracked once.

Right now the device driver stores SOME of that info as relates to the image train, but not all of it. Hence my confusion.

[TallFurryMan]

When reading the title I though "yeah, filter bandwidth as FITS attribute, configured in the INDI panel, good idea".

When reading the issue text, I was not so sure it was the intent anymore :)

Now that I read the second post, I think I understood properly at first. If the bandwidth information is a property of the device, and it could be helpful for clients, then it needs to be inside the INDI driver and distributed to clients for use. Thus the development is to be made first in INDI, then eventually suported in Ekos.

Looking up whether FITS headers exist for this data, I found the following attributes in the (old) Far Ultraviolet Spectroscopic Explorer [1] and a few others, illustrated with this example of values:

BANDWID =             99.99597 / [Angstroms] Bandwidth of the data              
CENTRWV =              949.998 / [Angstroms] Central wavelength of the data     
WAVEMIN =                 900. / [Angstroms] Minimum wavelength of the data     
WAVEMAX =              999.996 / [Angstroms] Maximum wavelength of the data     

As mentioned in [2] the problem remains if the optical train has more than one filter. I is also not possible to manage multi-frequency filters such as SHOO. However, these definitions could be used as a first step.

[1] https://archive.stsci.edu/fuse/DH_Final/FITS_File_Headers.html [2] https://archive.stsci.edu/mug/mug_2008/wfpc2_mug2008.pdf

[xthestreams]

Thanks TFM - I also sometimes think it's a good idea and other days think it's stupid. I am just starting to realise that the meta data that surrounds astro is such a large part of what makes the data useful, more in a scientific context, but sometimes for "pretty pictures" too.