×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

New astro imaging catalog software. Help testing needed

  • Posts: 398
  • Thank you received: 117
Hi Ferrante, on my system, Import fits tab has a left index for selecting entire rows. I don't have a similar selector index on the Images tab (but would like it). I hadn't realized that a double click on other fields would bring up the old Detail window. That's fine. On my system's Images tab, I don't get the opportunity to double click on filename. As soon as a single click is sensed, I get a Kstars and FITS viewer launch. So, I think my recommendation would change in favor of adding an index for row selection consistent with the import tab, and do nothing about the single vs double click.

We need help from someone who understands FITS viewer better. We'd prefer to avoid multiple copies of kstars. Not sure if that means a stand-alone copy of FITS viewer, or a different interface/setting. One copy of Kstars is ok (can always minimize). Several copies are undesirable. Cheers, Doug
3 years 9 months ago #54835

Please Log in or Create an account to join the conversation.

  • Posts: 249
  • Thank you received: 62
hi Doug,
some fixes in v 0.2.13:
- Delete multiple rows in Fits import and CSV imports.
- Added index column in image list. There's still an issue when sorting: the index keep always the same ordering.
- In the table, single click only selects an item. Double click opens the external viewer (if clicked on the file name) or the detail windows if clicked elsewhere.

ferrante
3 years 9 months ago #54908

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
yes, I confirm 0.2.13 works as advertised/expected. I don't have a problem with the index sort order remaining as is; it's just a useful handle for selecting whole rows. Cheers...
The following user(s) said Thank You: Ferrante Enriques
3 years 9 months ago #54910

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
Hi Ferrante, I was wondering your thoughts about a generalized CSV import capability for AD. There are lots of ways folks might want to associate/import CSV data, and it's likely impossible to think of them all specifically. Having a general CSV import interface might be ideal. Needed would be a way to associate the primary field (e.g. filename?), plus field name definition(s). Against those, import of values could proceed. For example, CCD_Inspector can generate useful CSV information (indirectly, through clipboard, but then via Excel -> CSV). Here's a sample of some fields of interest (there are other fields....this is just an example) that would be nice to associate:

Date & Time, Image File, FWHM, Aspect (%), Background (adu), Stars Used, Contrast Ratio, Curvature, Temperature
6/11/2020 1:16, M_27_Light_023.fits, 3.24", 14, 792, 2940, 31.59, 21.6, -5
6/11/2020 0:47, M_27_Light_011.fits, 3.29", 19, 712, 2949, 32.65, 33.1, -5
6/11/2020 1:16, M_27_Light_024.fits, 3.31", 25, 792, 2911, 31.91, 18.8, -5

Clearly, some pre-massage on data might be required of users (e.g. removal of " for arcsecs), but what do you think?
Could a mechanism for new CSV field(s) definition, plus an association key, allow import of more generic CSV data?
Just wondering.... Doug
3 years 9 months ago #55381

Please Log in or Create an account to join the conversation.

  • Posts: 249
  • Thank you received: 62
hi Doug,
the most flexible approach would be to allow the user to add custom fields to AD database: name of the field, type, format could be a minimum set. And then choose the source for these data, like CSV file, json, xml or even direct connection to a server. Filtering, sorting and plotting these data would be then straightforward.
It requires some restructuring of the code but it will be a nice improvement that will allow AD to be a single point of information for image metadata.

As of now I'm following another similar request by a github user (Rick) that suggested to import PHD2 guiding data through its log. It will allow to correlate guiding performance vs eccentricity or Alt/Az etc.
I'm not a PHD2 user so it's quite difficult to test. For example I'm not able to recreate the RMS calculation to have the same result as PHDLogViewer. Seemed to be easy but it's not.

A note about the filename as identifier key: names could change, files could be moved and different images could have the same file name. I chose a different approach that prevents these issues: hashing the file itself (a part of it, for performance reason). But for our understanding saying that file name is a key it is ok, I was just more specific because you're quite into the software details.

ferrante
3 years 9 months ago #55413

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
Not sure what you're chasing in the PHD log, but I would be interested in the details if you care to share them (as I too use PHD and the logViewer). I can't imagine why AD would want to read the PHD log directly as opposed to having a user prepare a CSV file for import. For Guide RMS (example), are you thinking just to average reported values over the exposure interval? Just thinking out loud here, but it seems that PI or CCD_Inspector (eccentricity, Aspect %) directly imply guiding performance (only entangled with coma for worst case collimation issues). I think the fundamental issue for AD is to work at the same time scale as the primary key (Fits file, thus exposure time). Working at smaller time scales seems fraught with integration problems (as you seem to be discovering). The nice thing about PI statistics and CCD_Inspector stats is that they're at the same time scale, so you don't have the issues that come from working on smaller time scales.
3 years 9 months ago #55458

Please Log in or Create an account to join the conversation.

  • Posts: 249
  • Thank you received: 62
hi Doug,
there's a thread on Github where there are additional details:
github.com/fenriques/AstroDom/issues/1

I preferred reading the log directly because it is more user friendly than manipulating a csv file. Anyway the difficult part was the logic processing the data not reading the file.
I do not guide but I guess that knowing the rms correlation with not only eccentricity but also with alt/az, filter or event different set ups would be helpful to improve guiding performance.

AD time scale will not be affected: as you correctly guessed, phd log data are integrated over the exposure time of the fits file and RA / DEC rms is calculated for that time interval.

Attached a screenshot of an early version.
3 years 9 months ago #55469
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
Yes...you seem to have it under control ;-) I'll check out the discussion on Github, but I like the RMS info in the GUI preview; I think I could make use of that info too.. Nice work.... cheers, Doug

p.s. I think in the not too distant future, there could be some buzz about Ekos using a 2nd, optional guide log format (at least partially consistent with PHD's log). This started as a discussion and proceeded though at least prototype by a developer to allow internal guider users to use the PHD LogViewer. Not sure where that effort stands, but it would open the door for Kstars/Ekos internal guide users to have the same info in the AD DB. I'll let the developer comment further (and if he doesn't, I'll send a separate note to urge him to comment).
Last edit: 3 years 9 months ago by Doug S.
3 years 9 months ago #55476

Please Log in or Create an account to join the conversation.

Time to create page: 1.492 seconds