Open ocacontrolroom opened 12 months ago
PS. Jeszcze bym wrzucił wysokość słońca - przyda się do statystki jasności filtrów przy flatach
oraz jak już słońce to może i księżyc. A tu najlepsza byłaby separacja i faza....
A moze także np. średnia czy inne statystyki...
Jedna tylko uwaga z mojej strony:
Jest różnica pomiędzy wejściem w reżim nieliniowy kamery a prześwietleniem. Zgadzam się, by SATURATE wpisać na poziomie 60000 ADU, ale też proponuję, by wpisać, że LINEARITY = 40000 lub 50000 ADU (konserwatywnie), przynajmniej dla większości modów gainu. Chyba tylko dla "1x" liniowość już się psuje przy ok. 25000 ADU (testy FLAT rampup, obrazek 23 tutaj)
jest:
XBINNING= 1 / Ccd binx
YBINNING= 1 / Ccd biny
winno być
CCD_BINX= 1
CCD_BINY= 1
(nie pamiętam skąd ta uwaga, @pkarczmarek zobacz)
@pkarczmarek :
Jedna tylko uwaga z mojej strony: liczyłem na więcej
pkt. 10. SATURATE
Jest różnica pomiędzy wejściem w reżim nieliniowy kamery a prześwietleniem. Zgadzam się, by SATURATE wpisać na poziomie 60000 ADU, ale też proponuję, by wpisać, że LINEARITY = 40000 lub 50000 ADU (konserwatywnie), przynajmniej dla większości modów gainu. Chyba tylko dla "1x" liniowość już się psuje przy ok. 25000 ADU (testy FLAT rampup, obrazek 23 tutaj)
tak, słusznie żeby nie mieszać saturacji z liniowością. Generlanie dla zb08
pixele saturacji - są na wykresie radialnym , nie osiągają granicy zapisu 16bit (65535). są na poziomie 64479 albo trochę mniej.
Jeszcze o SATURATE
, IMHO to powinno być rozumiane tak jak jest potrzebne oprogramowaniu do maskowania złych wartości (DAOPHOT, IRAF). Czyli dla x1 ~25000 ADU (okolice limitu studni), dla innych trybów ~65000 okolice limitu reprezentacji. na tą wartość pipeliny powinny ustawiać treshold górny. Pipeliny powinny również (@MMiirrkk) przekształącać tą wartość wraz z przeksztaleceniami wartości tablicy (przejście na float, odjęcie bias, normalizacja), aby maksa "złych" punktów pozostawała taka sama moreless.
Mirror-covers, dome-shutter, dome-az, To wszystko dodatkowo przyda się do szybkich quality check.
Prpozycja sekcji Quality by exmaple:
QC-SUN=0 / Quality Code [0,1,2] - Sun Altitude
QM-SUN='OK: Sun Alt < -18' / Quality Message [optional]
QC-FWHM=1
QM-FWHM='LOW: FWHM > 6px'
QC-INSTR=2
QM-INSTR=`BAD: Dome AZ diverged from telescope AZ`
QC-SATUR=0
QC-OPER=2
QM-OPER='BAD: OPERATOR: Kopula się zaciela'
...
QC=2 / Final Quality Code max(QC-x): 0-OK, 1-LOW, 2-BAD
QM='BAD: Some of quality flags are BAD, Recommendation: Reject frame'
trzeba wziąć pod uwagę że różne QC będą mogly być dodawane:
to trochę inaczej niż wcześniej gadaliśmy chyba, ale w sumie mi ta opcja pasuje.
ROWORDER
ROWORDER= 'TOP-DOWN' / Row Order
Może zastanowilibyśmy się i dodali take pole, wtedy program przeczytał by jaki jest row order i wyświetlił fitsa w prawidłowy sposób. No i nie trzeba by zmieniać milionów fitsów? To oczywiście propozycja.
PIERSIDE Już dodane do nagłówka
SITELAT i SITELONG
Odległóść do księżyca, wysokość księżyca, faza księżyca
Wysokość słońca
SCALE Skala zdjęcia
Apertura i focal lenght
Czy guided
Czy dome otwarte i czy lustro otwarte
The Mirka lista:
digitlaizacja by ChatGPT and Mikołaj:
1. DOME_SHU (Dome Shutter)
2. TELCOVER (Telescope Cover)
3. MOONDIST (Moon Distance)
4. MOONAZ (Moon Azimuth)
5. MOONALT (Moon Altitude)
6. PIXSCALE (Camera Pixel Size - skala w arcsec/pixel)
7. SUNAZ (Sun Azimuth)
8. SUNALT (Sun Altitude)
9. MOONPHAS (Moon Phase)
10. SCALE1M (Scale for 1M in arcmin)
11. APERTURE (Telescope Aperture)
12. MNT_TYPE (Mount Type, EQ/AZ)
13. FOCALLEN (Focal Length)
14. GUIDEMOD (Guide Mode - Pulse Follow Guide)
15. ROWORDER (Row Order - left-rigt / top-down)
16. WINDDIR (Wind Direction)
17. WINDSPD (Wind Speed/Value)
18. TEMPERAT (Temperature)
19. HUMIDITY (Humidity)
20. PRESSURE (Pressure)
21. DOMEAZ (Dome Azimuth)
22. DEWPOINT (Dew Point)
23. BSCALE (B Scale)
24. READMOD (Read Mode - HZ, NAME)
25. GAIN (Gain)
26. QUALITY (Quality)
podrkeślniki _
versus -
podrkeślniki
_
versus-
Lepiej _
, bo -
może być mylnie uznany za znak odejmowania (za "Definition of the Flexible Image Transport System (FITS)"). Ale ta sama publikacja wypisuje keywordy, które mają myślniki w nazwach (np. DATE-OBS
).
Moja propozycja: aby trzymać się myślników tam gdzie mamy wybór (znaczy, tam gdzie nie jest to ustandaryzowane).
14. Binning:
jest:
XBINNING= 1 / Ccd binx YBINNING= 1 / Ccd biny
winno być
CCD_BINX= 1 CCD_BINY= 1
(nie pamiętam skąd ta uwaga, @pkarczmarek zobacz)
ESO używa keywordu HIERARCH ESO DET WIN1 BINX
(analogicznie dla Y). Nie wiem, skąd się wzięło CCD_BINX, ale wolałabym o nim zapomnieć, bo może być tak, że w przyszłości nie wszędzie będziemy mieć matryce CCD i lepiej mieć keyword, który nie ma CCD w nazwie.
Po konsultacji z Chatem GPT wychodzi, że najczęściej używane keywordy na binning (choć niestety żaden nie jest standardowy) to:
BINX
, BINY
XBIN
, YBIN
XBINNING
, YBINNING
Moja propozycja: aby zostać przy XBINNING
i YBINNING
, bo są ok i już są używane.
Pytanie: czy XBINNING
dotyczy NAXIS1
a YBINNING
dotyczy NAXIS2
?
ESO documentation about FITS headers: https://archive.eso.org/cms/tools-documentation/dicb/ESO-044156_7_DataInterfaceControlDocument.pdf
The official reference document that defines the requirements for FITS format data files: https://fits.gsfc.nasa.gov/fits_standard.html
Dictionary of most commonly used keywords (also non-standard): https://heasarc.gsfc.nasa.gov/docs/fcg/common_dict.html
14. Binning:
Moja propozycja: aby zostać przy
XBINNING
iYBINNING
, bo są ok i już są używane.
brzmi rozsądnie.
Pytanie: czy
XBINNING
dotyczyNAXIS1
aYBINNING
dotyczyNAXIS2
?
Ha, trudne pytanie przy naszym krzywym zapisie matrycy. Będą korespondować z ALPACA BINX BINY na pewno.
Chyba czas kontynuowac dyskusje o FITS Headers, kontynuując tematy z #9
Oto moje (nowe) uwagi:
1. OCASTD:
"BETA3"
na"0.4.0"
(string).Myślę że przy okazji version bump przejść na
"x.y.x"
. Kiesyś będziemy musieli powównywać wesje etc i wtedy używanie standardy się opłaci.DONE
2. Dokumenacja refwerencyjna:
Jako referencję proponuję przyjąć: https://fits.gsfc.nasa.gov/standard40/fits_standard40aa-le.pdf Tutaj jest wąski podzbiór używanych przez nas nagłówków ale to chyba właśnie dobrze.
3.
EQUINOX
- floatW tej chwili zapisujemy jako string:
(sekcja 8.3)
4.
OBJECT
- przy obrazach kalibracyjnych.Mamy:
OBJECT
jest obowiązkowy ale nie wstawiabym tam pseudowartości - mamy to że flaty gdzie indziej. Dokumentacja:Proponuję dla FLAT albo nawet generalnie wstawiać nazwę TARGET z TOI, co by tam nie było - jak pusta to pusta.
Co do pozostałych trzeba by podyskutować:
Przypominam dyskuję (#9 ) o
zero
i IRAF. Tutaj też wniosek że IMAGETYP ma zawierać indykator "zero" czy "bias" a nie OBSTYPE.5.
JD
->MJD-OBS
Bo tak jest w standardzie, samo
MJD
lubJD
nie wiadomo do czego się odnosi (a w zasadzie odnosi się doDATE
czyli momentu stworzenia pliku a nie obserwacji), w duchu standardu jest suffix-OBS
lub inny tak dlaMJD
jak iDATE
.2024-10-17: Zostawiamy jak jest, niech sobie ludzie przeliczają. Ponadto dojdzie kiedyś do
DATE-OBS
DATE-END
(lub podobie).6. Uzupełnić units
W komentarzu po
/
, np. CCD-TEMP, FOCUS, RA_TEL7.
DATE
,TIMESYS
9.8:
Można by dodawać w
pyaraucaria
DATE jako data wygenerowania pliku. Może się przydać w workflowach, jak będziemy pisać zawsze - mniej ifologii.TIMESYS ma domyślnie
UTC
. Ale jak bardzo chcą toTIMESYS= 'UTC '
nam nie zaszkodzi.To co tam jest recomended a nie "strongly recomended" bym nie dodawał na siłę.
8. EXP-TIME vs XPOSURE i TELAPSE
Wygląda na to (9.7) że
EXP-TIME
nie jest standardowy. Można by rozważyć XPOSURE i/lub TELAPSE. Możemy pisać oba, bo TELAPSE jest chyba używany do obliczania czasu średniego ekspozycji DATE-AVG na przykład, który potem jest istotny przy timingu zmiennych obiektów. (no a XPOSURE to czasu integracji).See also: https://github.com/araucaria-project/oca-problems/issues/123
9. GAIN
Zgodnie z #9 wartości
GAIN_MOD
miały być typux2
. Co my na to? myślnik w nazwie czy podkreślenie. jakiev wartości, może zacząć zapisywać wartośćGAIN
iRON
jak je znamy?Teraz jest:
Chcemy mieć też informację
x4
albo jak komentarz, albo (i pewnie tak będzie) nowe pole typuGAIN-NAM='x4'
10. SATURATE
Float lub integer.
SATURATE
w obrazach skalibrowanych powinno być w skali obrazu skalibrowanego. (albo skalibrowane przesuwamy do RAW albo przeliczamySATURATE
)11. O "trailing spaces"
4.2.1.1:
12. OBSERVAT = "OCM"
12.5 CAM-SN
Serial number kamery - sprawdzić -> manual -> configuracja projekt
ocabox-config-ocm
:/tree/<tel>/observarory/components/camera/camera_sn
-> nagłówki FTISCAM-SN
.13. Komentarze
/
Nie wiem czemu po postych polach
'= '
komentarze idą od razu, a chyba powinny być "klasycznie" od którejś kolumny. Ale to chybaastropy
?BTW, a'propous pustych pól 4.1.2.1:
ale nie ma czegoś takiego jak "null float keyword"...
To pewnie nie wszystko, można jeszcze raz zrobić przegląd przykłady @pkarczmarek .
Na dobranoc aktualny header: