I had edited my previous post to add more information. I had hoped to update it before you read it, but was not quick enough

good to know that you fix it! and that you find it useful.

I never thought of intermediate processing files...but if Astrodom doesn't find the right keyword in those files it should just skip them when saving to database (and not block other imports).
On the other hand it should work fine for Dark, Flats and Bias.

The frame type filter is a good idea. Even though not everybody put the name in the folder's name and even the keywords are not always the same.

If using it you find something else that could be improved let me know.

ferrante

FYI, in case it wasn't obvious, for those who are having problems during installation when using python3.8, the astrodom_linux_run.sh script line must be manually changed to the following:
cd ./venv/lib/python3.8/site-packages/
Afterwards, the app will load / run. otherwise, you'll get errors indicating that the 3.6 site-packages tree files aren't found.

thanks for bringing up that issue. i will fix the script adding a check for existing python version. Can you please check if the following works also for you?

#!/bin/bash
cd $(dirname "$0")
source ./venv/bin/activate
if [ -d "./venv/lib/python3.6" ]
then
cd ./venv/lib/python3.6/site-packages/
elif [ -d "./venv/lib/python3.7"]
then
cd ./venv/lib/python3.7/site-packages/
elif [-d "./venv/lib/python3.8"]
then
cd ./venv/lib/python3.8/site-packages/
else
echo "python not found"
exit 0
fi
export QT_SCALE_FACTOR=1
python3 -m astrodom
deactivate

You need to include a few spaces in particular locations within your script. On lines 4, 7 and 10, you need to add a space char to avoid shell confusion. After [ and before ] in each line, add a space char....then it works.
cheers, Doug

It was just missing some spaces, then works:

A few initial impressions. REALLY nice! Thanks for doing this. Here's some suggestions to consider:
a. in the import fits tab, is unique hash really needed by the user (or can it just be a hidden field)?
b. import fits tab: To save GUI real-estate, I suggest shortening some names: Targ, Frame, Exp, Cam Temp, Site Lat, Site Lon. Idea is GUI space is precious...
c. Images tab: Same idea to shorten names as on import, but also: Eccen, SNR Wt
d. There are a few fields missing that I think we'll want in the future (when Ekos is ready...not yet, but hopefully in the future): Env Temp, Foc HFR, Seeing.
I'm not sure when these extra fields might get added, and it might be a pain to edit to add in the meantime, but could be very useful to have in the archive. Something to think about....
Finally, I think having screen resize capability would be highly desired. I can't seem to figure out how to resize (or it's not there)?

I'll play some more and give more feedback.... In the meantime, this is a fun tool to explore!

Thank you! any advice is appreciated.

It can be a hidden field. but it is also the one used to highlight errors if the imported file is already existing in the database. You have the same message in the log window but here is more in the context.

I use AstroDom on a wide display...BUT if you want you can customize those name, they are stored in a json file: /venv/lib/python3.x/site-packages/astrodom/config/profile-EkosIndi.json
just change the 'description' values.
I suggest that you save (in Settings) a new custom profile to have a working backup and to avoid conflict when upgrading AstroDom. Tell me if you succeed in doing this.

Same as above

Exactly! I build it with the idea to expand the fields in the future The keyword list is almost dynamically loaded.

It's my first QT application....if someone could explain how to resize windows I will be very happy to implement it.

I did succeed in changing those field names. Sufficient enough. A few more comments:
- The filename and Date fields should probably have slightly wider defaults. The Ekos date field is clipping. Easy enough to adjust, but with a larger default, it wouldn't.
- It would be very nice if any user adjusted field sizes were remembered. I know....it's easy enough to do each session. The user experience across sessions would be better. This should go for the import tab fields too.
- The last field of the import tab doesn't work as nicely as the last field of the images tab. You can't grab / downsize that last field to desired width so the header stays with the data.
- longer term, should you consider having the last field for "Comments" on the images tab? That might find use by some users...
- About that hash field, I recommend calling that "Status". Save the hash value internally and give a "Ready", or "Ready to Import" value until successfully imported?
- In settings, should the "hide" selector operate on both import tab and image tab fields? I realize that if hidden, it could cause confusion if any hidden import field wasn't right, but seems this could be overcome by a message. Just a thought.

Edit - a couple more (I think I'm done now):
- Recommend sexagesimal (hours) format for RA. Dec too (degs). It's pretty ubiquitous in the amateur community. I know astronomers get used to degrees for both, but....
- also, need a way to delete rows from the DB (image tab).

I'm having problems importing Pixinsight CSV files. I'm also having a few core dumps. The main app seems to work ok to import image files, but when I attempt to import/associate the csv stats from Pixinsight's subframe selector, the app reads the CSV file ok, but complains it can't find the fits files to associate the data to (even though all fits have already been successfully imported to the DB and show up on the images tab). Looking at the terminal output as the app runs and sometimes cores (I've seen a "cancel" operation core a couple of times), I see these lines:

apparently non-fatal lines:
======================
QGridLayoutEngine::addItem: Cell (3, 1) already taken (often many lines repeated)

AstroDom-master/resources/venv/lib/python3.8/site-packages/numpy/core/fromnumeric.py:3334: RuntimeWarning: Mean of empty slice.
return _methods._mean(a, axis=axis, dtype=dtype,
AstroDom-master/resources/venv/lib/python3.8/site-packages/numpy/core/_methods.py:161: RuntimeWarning: invalid value encountered in double_scalars
ret = ret.dtype.type(ret / rcount)
AstroDom-master/resources/venv/lib/python3.8/site-packages/numpy/core/_methods.py:216: RuntimeWarning: Degrees of freedom <= 0 for slice
ret = _var(a, axis=axis, dtype=dtype, out=out, ddof=ddof,
AstroDom-master/resources/venv/lib/python3.8/site-packages/numpy/core/_methods.py:185: RuntimeWarning: invalid value encountered in true_divide
arrmean = um.true_divide(
AstroDom-master/resources/venv/lib/python3.8/site-packages/numpy/core/_methods.py:209: RuntimeWarning: invalid value encountered in double_scalars
ret = ret.dtype.type(ret / rcount)

Fatal lines:
==========
Traceback (most recent call last):
File "archive/AstroDom-master/resources/venv/lib/python3.8/site-packages/astrodom/mainWindow.py", line 279, in dialogChart
self.chartWindow.plot(self.imageListModel)
File "archive/AstroDom-master/resources/venv/lib/python3.8/site-packages/astrodom/chartWindow.py", line 184, in plot
self.lrDate = pg.LinearRegionItem([min(timestampObj), max(timestampObj)])
ValueError: min() arg is an empty sequence
./astrodom_linux_run.sh: line 6: 242224 Aborted (core dumped) python3 -m astrodom

Another Fatal (different run-time instance):
====================================
Traceback (most recent call last):
File "archive/AstroDom-master/resources/venv/lib/python3.8/site-packages/astrodom/importCsvTab.py", line 67, in importCsvFile
for row, val in enumerate(dataTemp):
UnboundLocalError: local variable 'dataTemp' referenced before assignment
./astrodom_linux_run.sh: line 6: 242696 Aborted (core dumped) python3 -m astrodom

Not sure what I'm doing wrong or if there's a Python 3.8 incompatibility....I think I followed flow as per the youtube video. Let me know if you'd like additional info to chase......

Wow this is really exciting! Looking forward to using it on my data!

hi Doug,
I will test it with python 3.8 too as there are many people using that version.

Can you send me the CSV file you're trying to import?

Are you using the CSV file exported from PI SFS on your original FITS files (the ones you imported in Astrodom) or the .xisf file that are we usually export during the calibration process?
If it's the latter, AstroDom won't be able to work because there are no standard library to read data from .xisf files.

But reading your email better, you are able to read the content, AD complains about not finding the matching FITS file. Could it be that you moved the files after exporting the CSV? or in some way you altered the original FITS file?
To help you debug this is how AD works :
- when importing FITS file AD stores a hash of the files itself. That's more reliable than the filename as unique key in the database.
- when importing CSV it looks for the file name stored in the CSV file (and the file must exist in that path), try to open it and calculate a hash. Then look in the database for that hash / key.
- if a hash key is found, it can update the corresponding record.

I just hope the issue is not related to different PI versions because it will be hard to keep track of that.

Error output seems to be related to charts that are not reading all the values: could it be the CSV or the date format.
To better debug, can you also send me your database? it's the .db file in /venv/lib/python3.8/site-packages/astrodom/config/

ferrante