Aktualne Studia

AKTUALNE DZIALANIA

20060215 - Zakonczylem wlasciwie testowanie procedury kalibracji osi montazu
zostala ona przetestowana ( heplx43:$RESDIR/simul/ccddouble/mount_calib, plytka )
Teraz trzeba by juz na zywym organizmie, opis procedury jest tutaj

1/ Aktualnie badam szbka fotometrie, skatalogowalem noc 20050511 przy pomocy 4 algorytmow :

szybka fotometria :
http://grb.fuw.edu.pl/pi0/daq/curves/heplx43/20050511_fast/
http://grb.fuw.edu.pl/pi0/daq/curves/heplx43/20050203_fast/
asas fotometria :
http://grb.fuw.edu.pl/pi0/daq/curves/heplx43/20050511_asas/
srednia z 20 pomiarow szybkiej fotometrii :
http://grb.fuw.edu.pl/pi0/daq/curves/heplx43/20050511_fast_aver/
szybka fotometria na klatkach posumowanych po 20 :
http://grb.fuw.edu.pl/pi0/daq/curves/heplx43/20050511_fast_onsum/
Dodatkowo zrobilem plot sigma po katalogowaniu vs sigma przed katalogowaniem dla kazdej gwiazdy : sigmacat_vs_sigma , myslalem ze on pomoze mi cos
zrozumiec ale chyba nie pomogl , widac ze z grubsza katalogowanie dziala tak :
1. W najlepszym przypadku :
  Sigma_cat ~= Sigma - MEAN(sigma)
2. W najgorszym przypadku :
  Sigma_cat ~= Sigma
Natomiast taki sam plot dla katalogowania szybkiej fotometrii : sigmacat_vs_sigma_FAST , sigmacat_vs_sigma_FAST_fit, fit_power
Wyglad tego plotu z fit_power wlasciwie wyjasnia to, ze katalogowanie szybkiej fotometrii i potem sredniowanie jest lepsze od sredniowania i katalogowania
Skoro : Sigma_cat = 0.9184*(Sigma - 0.07886)^0.66084 - 0.0709 , to dla :
1. Szybka skatalogowana i potem srednia mamy :
  Sigma_final = ( 0.9184*(Sigma - 0.07886)^0.66084 - 0.0709)/sqrt(N) ~= 0.9184*Sigma^0.66084 / N^0.5 - 0.0709/sqrt(N)
2. Srednia z 20 skatalogowana :
  Sigma_final2 = ( 0.9184*(Sigma/sqrt(N) - 0.07886)^0.66084 - 0.0709) ~= 0.9184*(Sigma^0.66084)/N^0.33 - 0.0709
I widac ze Sigma_final2 > Sigma_final , wyglada na to ze tak jest wynika z tego jak dziala katalogowanie.
sigma asas ( /20 ) vs sigma fast averaged by 20 : plot ( in heplx43:/pi20/msok/fast/COMPARE/asas_nonorm/CAT_VS_NOCAT/ALL )
(sigma asas) / (sigma fast averaged 20 ) vs sigma_no_cat_single_frame : plot , ratio vs sigma without cataloging

2/ Katalogowanie szybkiej fotometrii zapuszczonej na klatkach posumowanych po 20 z ASAS-PIPELINE
    Problem jest w ustawieniu progu przy ustawieniu progu na 1.5 lub 2 sigma gwiazd jest duzo ale blad jest duzy i astrometria
    nie chce zbiec ( moze trzeba by ustawic
    wiekszy dopuszczalny blad astrometrii ) , ale jak sie ustawi T=3.5 to astrometria zbiega , tyle ze wtedy tracimy czasem slabe gwiazdy o
   jasnosci >=11mag, maja one mniej pomiarow np zamiast 80 przy normalnej asas-photometry maja 50 , stad ten brak punktow dla slabych gwiazd
Oczywiscie mozna jeszcze pokombinowac z progiem, moze 3 lub 2.5 bedzie bardziej optymalny i osiagnie sie to co w ASAS, do celow
porownania rozrzutow pomiarow nie robilem takiego sprawdzenia

uwaga techniczna, przy zapuszczaniu szybkiej fotometrii i asas-astrometrii na fitsach posumowanych po 20 ( katalogi red1/red2 z ASAS-PIPELINE)
Ustawilem : fotometria bez flipa , tresh=3.5 , astrometria - "fi 180"

3/ badania skryptu sumujacego average_measurements.pl robilem w :
    heplx43:/opt/pi/dev/pisys/daq/ndir/results/FAST/aver

4/ Porownanie sigma vs mag :

5/ Porownanie kilku krzywych blasku

GWIAZDA	ASAS-PIPELINE ( asas -fotometria na sredniej z 20 klatek )	SREDNIA z 20 pomiarow szybkiej fotometrii
122755-0867.5	asas	pi_aver
125712-1205.9	asas	pi_aver
123954-0306.5 - bad	asas	pi_aver
	asas	pi_aver

6/ Wnioski , wyglada faktycznie lepiej, przynajmniej dla duzych gwiazd, problemem bedzie tu zasieg bo szybka fotometria ma maly zasieg

7/ Porownanie z M.Gorskim , nasz

8/ test 5 apertur kolowych ( dane 20050511 ) do porownania ze standardowa apertura 3x3+3 :
       r = 1.5 2.0 2.5 3.0 3.5

    sa nowe bazy - na razie musze je obejrzec 20050511_new_ap0, 20050511_new_ap1, 20050511_new_ap2 , ...
     Zapuszczanie na heplx43 w /pi20/msok/fast/NEW_TESTS/aperture/ast1

Musze to jeszcze sprawdzic ale nie wiem dlaczego jest taka roznica w liczbie gwiazd dla ap=2.5 i ap=3.0 ??? , powinny byc praktycznie
takie same - sprawa wyjasniona , chodzi o to ze teraz puscilem z wiekszym promieniem matchowania 120 arcsec ( wczesniej bylo 60 arcsec )
stad np gwiazda 17252 , a w starej wersji zostala podzielona na 3 gwiazdy po 300-500 pomiarow

9/ Do zbadania jest sprawa promienia matchowania , dla klatek posumowanych po 20 optymalny byl radius=120 arcsec, ale dla scanow jest inny
   bo astrometria ma wieksze bledy trzeba to wyznaczyc i skatalogowac jeszcze raz !

badania promienia matchotwania dla asas-pipeline ( klatki posumowane po 20 i asas fotometria ). Badam to na bazie 20050511_asas2 w katalogu heplx43:/pi20/msok/badania/match_radius/asas

Ploty : http://grb.fuw.edu.pl/pi0/user/msok/cataloging/matching_radius/asas/20050511/
promien matchownia dla scanow , kataloguje sie na heplx46 jedno pole scanu S0448-60 - 71 obserwacji , do bazy S0448_60

kataloguje sie w : /opt/pi/dev/pisys/daq/ndir/data/ast/scan/by_field/NEW/S0448-60, baza ta jest dostepna przez WWW w :
http://grb.fuw.edu.pl/pi0/daq/curves/heplx46/S0448-60/

ploty w : http://grb.fuw.edu.pl/pi0/user/msok/cataloging/matching_radius/
Wyglada na to ze promien matchowania dla scanow moze byc podobny jak dla asas pipeline ~120 arcsec
Czyli te zeby w plotach Kasi ( szpliki ) sa raczej wynikiem jakiego tla - trzeba sprawdzic jakiego
Ploty Kasi : http://www.fuw.edu.pl/~kkrupska/wykresy.htm

Chyba wiem o co chodzi ten szpilki sa chyba wynikiem otwartej migawki w k2b ! Czy Kasia mogla by zrobic taki
sam plot tylko jakos tak zeby dzialac na danych kiedy k2b mialo dobra migawke ? ( czyli rok 2004 ? )
Tzn chodzi o to ze na danych z otwarta migawka mamy przeswietlenia w postaci przelewajacego sie ladunku - sprawdzic
wspolrzedne x,y nowych gwiazd
dla szybkiej fotometrii robi sie na bazie 20050511_fast2 w heplx43:/pi20/msok/badania/match_radius/fast
baza sie na razie robi w : /pi20/msok/fast/COMPARE/fast/20050511
Chodzi o to ze baza 20050511_fast miala zle wypelnione pole measurements.dec = stars.dec - czyli takie same dla wszystkich pomiarow :-(

10/ Badania sposobow na czyszczenie bazy danych z pojedynczych pomiarow , ciekawe ploty : http://grb.fuw.edu.pl/pi0/user/msok/cataloging/scan/
badania na heplx46:/opt/pi/dev/pisys/daq/ndir/data/badania
Rozklad liczby pomiarow gwiazd : http://grb.fuw.edu.pl/pi0/user/msok/cataloging/scan/nobs/

11/ Testy nowego pi-pipeline na heplx48 :

/opt/pi/dev/pisys/daq/ndir/data/photo/asas
Na razie zapuszczam asas-pipeline na danych z LCO 20050301 , komenda :
nohup cat_both_synchro! night_list /scratch/pi_asas/results/ASAS_PIPELINE/ 20050301_asas > out 2>&1 &

12/ Nowy asas-pipeline - onlinowy tzn catalogowanie on-line porownanie zwyklego ASAS-pipeline i nowego PI-pipeline :
                        asas pi

13/ Widze ze cos troche dziwnie dziala ten on-line pipeline , tzn inaczej sie skatalogowalo niz normalne asty z asas-pipeline np mozna porownac
selecty :
    a/ 20050301_test3 :
          select frame.id_frm,spathtofile,ccdx,ccdy,magnitude from frame,measurements where star=58944 and
frame.id_frm=measurements.id_frm order by id_frm;
      klatka id_frm=162 ( 24 ) oraz id_frm=180 (42) ma podwojnie ta sama gwiazde - czym to jest spowodowane - sprawdze
      asty czy to wynika z parametrow astrometrii czy pozniej z katalogowania ???
    b/ 20050301_asas :
          select frame.id_frm,spathtofile,sobject,ccdx,ccdy,magnitude from frame,measurements where star=55761 and frame.id_frm=measurements.id_frm                     order by id_frm;
       klatka 24 to 127 ( k2a_050301_020.ast ) , a klatka 42 to 145 ( k2a_050301_038.ast )

   Czyli wyglada na to ze roznica jest juz na etapie astrometrii, asty sie roznia - sprawdzic parametry astrometrii - porownac z ta w ASAS-pipeline

   Mozna to sprawdzic :
       cd /opt/pi/dev/pisys/daq/ndir/data/photo/test2/20050301/ast1
         find_star_ast! list 1039 1883
         11.00467 -14.0626 11.761 10.762 10.014 9.590 9.360 1039.7 1883.4 1.26 0.61 k2a_050301_024.ast
         11.00304 -14.0856 10.043 9.582 9.411 9.314 9.259 1038.3 1884.9 0.74 0.09 k2a_050301_024.ast
   i porownac z :
           cd /opt/pi/dev/pisys/daq/ndir/data/photo/asas/tmp
          find_star_ast! list 1001.3 157 5

Jasne - zapuscilem astrometrie ( skrypt - do_asas_phot_astro.sh ) jeszcze raz na fitsach z asas-pipeline i wyszlo tak samo jak w asas pipeline , czyli
problem sie juz pojawia na etapie redukcji ( a nie photometri/astrometri !!! ) , bo z tych samych fitsow posumowanych po 20 wychodza te same asty
   to tam pojawiaja sie roznice pomiedzy tymi dwoma sposobami ! zobaczyc :
          cd /opt/pi/dev/pisys/daq/ndir/data/photo/new_astro/ASAS/ast1
          find_star_ast! list 1001.3 157 6

mam flipniete fitsy asas-a w:
    /pi20/msok/tmp/fits/asas_fliped/k2a_050301_020.fit
do porownania z moimi srednimi w :
    /pi20/msok/tmp/fits/2/k2a_050301_024.fit
wygladaja dosc podobnie !, poziom tla podobny , sprawdze teraz photometrie/astrometrie i zobacze co z nich wyjdzie !

Teraz nalezy sprawdzic orginalne fitsy i darki i zobaczyc o co tu chodzi ...

Widac ze poziom tla jest ~4000 dark ma ~2000 -> 2000 i trzeba podzielic przez flat-a i jakos to dziwnie wychodzi nie wiem jak to mozliwe ze

w asas pipeline z tej samej nocy wyszlo poziom dla na sumach ~1000 !!!????

Uzyc summ i red_frame i sprawdzic czy wyjdzie to samo co moim ?

Czyli redukcja ASAS jakos jeszcze obniza tlo !!! :

    cd /pi20/msok/tmp/fits/2/single/
    cp SAV/*.fit .
    rm -f list_sum summ_000.fit
    summ list list_sum
    plik summ_000.fit - ma jeszcze wysoki poziom tla , ale ten po redukcji red1/summ_000.fit juz niski !!!
    red_frame list_sum list_red dark1.fit /opt/pi/dev/pisys/daq/ndir/data/FLAT/FLAT_k2a.fit 0 0 1.0 red1/ 1 phot1.lck
    calcfits summ_000.fit FH s_fh.fit -border=0

Sprawdzic co bedzie jak dark=0 i flat=1 ??? , czy moze to jakis rozjazd w rozmiarach fits-ow ???

Wejsc tutaj : /pi20/msok/tmp/fits/2/TEST/fits i uzyc plikow z ktorych powstala ta suma do summ / red_frame i zobaczyc co z nich wyjdzie
Zrobilem to w :
     cd /pi20/msok/tmp/fits/compare/asas/sum/red1/fits
     tu jest jeszcze raz otrzymana klatka z tych samych plikow ktore uzyl moj pipeline - zrobiona przez summ i red_frame :
          summ k2a_list list_sum
          red_frame list_sum list_red dark1.fit /opt/pi/dev/pisys/daq/ndir/data/FLAT/FLAT_k2a.fit 0 0 1.0 red1/ 1 phot1.lck
          ./find_star_ast! list 1030 1877

i teraz jeszcze raz chyba wezme te klatki i recznie moim pipeline jest zrobie ...
zrobilem to w : /pi20/msok/tmp/fits/compare/pi/sum/ wychodzi tak samo jak poprzednio moj-pipeline czyli inaczej niz asas-pipeline , pytanie gdzie
jest roznica w summ czy w red_frame ????
Trzeba szukac dalej ...

Zrobilem tak ze uzylem klatki z summ i poddalem ja mojej redukcji i wynik jest taki jak przy asas-pipeline czyli lepiej !!!! czyli tak
jakby moje sredniowanie jest gorsze !!! /pi20/msok/tmp/fits/compare/asas/sum/pi_red/s_fh.fit - jest tylko jedna gwiazda :
       cd /pi20/msok/tmp/fits/compare/asas/sum/pi_red/ast1
       ./find_star_ast! k2a_ast_list 1039 1883
       11.00303 -14.0853 10.045 9.583 9.410 9.316 9.264 1038.3 1884.9 0.63 0.08 s_fh.ast

EUREKA : czyli sredniowanie jakie sie wykonuje w programie pi_red_frame jest inne niz to zrobione przez calcfits2 !!!!
Bo na takiej sredniej robionej przez calcfits2 jest tylko jedna gwiazda w okolicy , a na tym pi_red_frame sa 2 !!! :
       cd /pi20/msok/tmp/fits/compare/pi/sum
       calcfits2 -list=k2a_fits_list -aver=20 -dir=CALCFITS/

COMPARISON :
     cd /pi20/msok/tmp/fits/compare/pi/sum/
     calcfits2 -list=k2a_fits_list -aver=20 -dir=COMPARE/
    pi_red_frame k2a_fits_list -list -do_object_list=object_list -sum=20 -out=COMPARE -aver_last=1 -outlist=aver_list
     tu sa identyczne fitsy ( bez redukcji ) :
          /pi20/msok/tmp/fits/compare/pi/sum/COMPARE/fits
    a teraz spradze jak to bedzie po redukcji

Czyli jak zrobie programem summ to jest lepiej niz jak zrobie moja sume ! Ostateczny wniosek - roznica polega na programie sredniujacym !!!!

OSTATECZNE POSZUKIWANIA : /pi20/msok/tmp/fits/compare/FINAL/CALCFITS/
co to jest ze z identycznych praktycznie fitsow wychodza troche inne magi i asty ???? - i to na moja niekorzysc ... :
k2a_050301_fh.fit   i    summ_fh.fit

Pre - wnioski :
- photometry zapuszczone na fitc dziala inaczej ( chyba gorzej ) niz
na fit !!!!!!!!!!!!!!!!!!!!!!
Jakos to trzeba poprawic !!!
Przetestowac na razie bez kompresji !
Dziala taki z photometria na nieskompresowanych - moze trzeba
bedzie pojsc dalej i zrobic zeby pi_red_frame wogole nie kompresowal
skoro tak to zle dziala!
        /opt/pi/dev/pisys/daq/ndir/data/photo/new_version/new_nocompr/20050301
baza 20050301_nocompr - to samo ale w wersji prymitynej

- mocna sie rozni fotometria tej samej klatki w funkcji odbicia !!!
laduje sie baza ktora ma odbicie FV i -fi 180.7 - ciekawe czy bedzie
lepsza niz 20050301_new ??? ktora byla FH i -fi 0 ???
cd heplx48:/opt/pi/dev/pisys/daq/ndir/data/photo/new_version/new_fv/20050301
To juz chyba jest kwestia szczesicia ze jedna jest lepsza od drugiej

DOBRA - NARESZCIE !!!!!!!!!!!!!!!!!
wyglada na to ze photometry na skompresowanym dziala jakos gorzej !!!!
dlatego trzeba dodac do pi_red_frame opcje zeby nie kompreasowal i potem
dzialac na niekompresowanych
DOPISAC DO DOKUMENTACJI , ZE photometry zle dziala na fitc ... :-(((
        20050301_test3 - ostateczna wersja bez kompresji sum
        20050301_nocompr - bez kompresji wersja experymentalna

zrobic pi-pipeline z wycinaniem ramki, sprawdzic czy z wycinaniem ramki +
kompresja nadal bedzie ok - tzn 2 gwiazdy
zapuscic katalogowanie - on-line pipeline i sprawdzic czy z wycieciem
ramki jest lepiej niz bez
Investygowac ten bug w compresji - ze sie robi +1 wartosc na fitsie !
Ostateczny wniosek - widac ze wycinanie ramki trzeba dodac

13/ kolejne badania 2005-12-30 :
     ciagle cos nie tak w pi-pipeline ??? mam ta sama gwiazde (id=56379)
   2 razy na tej samej klatce 85 ( k2a_050301_088.fitast.ast ) :
        http://grb.fuw.edu.pl/pi0/daq/curves/heplx48/20050301_test3/lightCurveD
Natomiast na asas-pipeline jest OK !

        (935.971,945.788) :
cd /opt/pi/dev/pisys/daq/ndir/data/photo/FINAL_VERSION/20050301/ast1
find_star_ast_radec! tmp_list 10.92844132 0.73871395
10.92703   0.7529 11.524 10.225 9.576 9.297 9.202 936.0 944.7 1.29 0.76
10.92833   0.7349 9.654 9.351 9.269 9.216 9.183 937.2 945.8 0.62 -2.00

na asas : (1093.85,1087.2)

TO TU :   /pi20/msok/tmp/pi_pipeline/NEW_TEST/ !!!!

14/ Wnioski ostateczne z badan nad pi-pipeline :

trzeba obcinac ramke 24,8,8,8 i dopiero robic photometry/astromtry
photmetry dziala inaczej na fitc niz na fit !!! I to wyglada jakby gorzej dziala !!! nie wiem czemu, ale tak jest
stad trzeba ja puszczac na klatkach rozcompresowanych
compr powoduje ze wartosci na klatce robia sie +1 !!!!!!!????? Potem ucompr juz tego nie usuwa, czyli compr dodaje nam 1
i to moze trwac , kazdy kolejny compr psuje nam obrazek !!! Trzeba sprobowac chyba to jakos wytropic w tej procedurze rice_compr !!!
roznica jest tez taka ze ja robie srednia w locie - i nie zapisuje posredniego wyniku jako (short int) tylko dziele przez flata wynik sredniej - czyli powinno byc lepiej !
a jest jakby gorzej ... jak zmienilem w pi_red_frame zeby po sredniej i odjeciu darka zaokraglic przez my_round , a potem dopiero dzielenie przez flat-a to
sie zrobilo OK - ze jedna gwiazda tak jak dla red_frame ( /pi20/msok/tmp/pi_pipeline/NEW_TEST/fit/20050301/pi/empty/ast1 ) , to dziwne ze to ma AZ TAKE ZNACZENIE???!!
ale netto to jednak wychodzi lepiej jak sie porowna pi i asas to jednak roznica jest ewidentna w pi sigma jest mniejsza , czyli pi-pipeline wyglada lepiej !

15/ To do czego doszedlem to ze w obu przypadkach pi-pipeline i asas-pipeline zdarzaja sie odstajace pomiary i sa one w wiekszosci wynikiem znalezienia przez fotometrie w obrebie
      tej samej gwiazdy 2 gwiazd z ktorych jedna ma mocno rozna jasnosc od drugiej. Pewnie dopoki sie nie dorobimy lepszej fotometrii ktora nie bedzie miala takich problemow
      mozna to wykrywac na etapie katalogowania i :
                  a/ nie wrzucac zadnego pomiaru jesli na jednej klatce sa >1 pomiary
                  b/ wrzucic lepszy - pytanie jak dobrac lepszy - blizszy sredniej ????
   Przyklady :
       http://grb.fuw.edu.pl/pi0/daq/curves/heplx48/20050301_asas/lightCurvePage.php?starId=60415
       http://grb.fuw.edu.pl/pi0/daq/curves/heplx48/20050301_asas/lightCurvePage.php?starId=61204
       http://grb.fuw.edu.pl/pi0/daq/curves/heplx48/20050301_asas/lightCurvePage.php?starId=61292

Takze wyglada na to ze jest to dosc ewidentne ze jak na jednej klatce gwiazda ma >1 pomiar to jest cos nie tak i poki co poniewaz nie umiem chyba inaczej trzeba oba odrzucic ???
chociaz mozna sprobowac odrzucic ten bardziej odstajacy i zostawic ten blizszy sredniej ?

16/ robienie retry w do_astrometry z wiekszym dopuszczalnym bledem astrometrii niewiele daje, bo powoduje ze potem klatka jest odrzucana na katalogowaniu z powodu zbyt duzego
      bledu astrometrii !

17/ Poszukiwania flar : pi_zebranie
katalog : /pi20/msok/badania/flares , skyrpt histo2var.C - wynik width_vs_mag.txt , pokazujacy jaka jest srednia szerokosc krzywej blasku w funkcji magnitudo
( w paskach po 0.2 mag srednia i rms tej szerokosci )
   I/ stopien selekcji flar takie gwiazdy ktore maja (mag_max-mag_min) >= <delta_mag>(m) + 2*sigma_delta_mag(m)
       w plikach :
             averwidth_vs_mag_range.txt - wartosci sredniej szerokosci w przedzialach magnitudo
             rmswidth_vs_mag_range.txt - wartosci rms szerokosci w przedzialach magnitudo
      trzeba by zrobic fit, ale na razie uzywam funkcji w pliakch : get_mean_magdiff.sql get_rms_magdiff.sql ( pidb/sql/anal )
     majac to mozna dokonac I stopna selekcji ktory daje ... # gwiazd = ~2541
   II/ stopien selekcji
     zeby # punktow odstajacych powyzej diff_limit ( mag_min + limit_diff ) byla >=2 i sa to sasiednie pomiary
     czyli wchodza mi takie ze jest jeden punkt nisko ( odstajacy ) i potem limit sie wylicza tak ze duzo punktow jest powyzej !
     Trzeba jakos pominac te skrajne pomiary - na razie zrobie tak ze znajde min2 i sprawdze min-min2 jesli >0.1 to jako min wezme min2 i tak dalej az min-min_new<=0.1
      Lepiej zrobic rozklad i odciac te od momentu gdy w jakims binie jest 0 : od min_mag do max_mag zrobic histogram co 20 binow i w ten sposob wybrac final_max_mag
      Trzeba znalezc pas w ktorym jest wiekszosc pomiarow min_mag i max_mag
III/ nalezaloby teraz znalezc jakas ewidentna gorke na krzywej blasku i juz !
      Juz chyba wiem - policzyc srednia magnitudo dla punktow w pasku final_max_mag - final_max_mag+dM potem dla punktow >min_mag sprawdzic czy maja postac piku
      i ile nad linie ograniczajaca wystaja

Analize flar robie teraz na nocy z 2004_2005 , heplx49:$DATADIR/flare/NEW/ - ale cos mam na razie nie tak i badam sprawe, dziala to dosc szybko cala baza ~24 h

18/ W toku studiow nad flarami odkrylem, ze chmury moga powodowac pseudo-flary oraz pojasnienia, wynika to z malej liczby gwiazd na klatce
uzytych do normalizacji i wtedy zle to dziala powodujac bledne pomiary jasnosci - widac ze na klatkach z k2a / k2b w LCO to mniej niz 15000 gwiazd
powoduje ze zaczyna sie problem - stad te problemy nad ranem czy przy przejsciu chmury