Pixinsight i za mało pamięci RAM ; czy stakować na raty?

[poldip]

Od kilku lat mam qhy163 (20Mpix), coraz więcej zebranego latami materiału, zero czasu na obróbkę. Ostatecznie zawziąłem się i postanowiłem obrobić najświeższe udojone z wielkim trudem klatki. Skalibrowałem, wyrównałem i zabrałem się za stakowanie. I tu ZONK. Pixinsight uprzejmie poinformował mnie że ma access violation do pamięci, innymi słowy moje 16GB ramu jest mu za mało (komp chodzi pod Win7). Mam w sumie 70-parę klatek obiektu w kanale Ha. Drogą eksperymentalną ustaliłem że mogę zestakować nie więcej niż 43 klatki na raz. Mniej tak, więcej nie.

I teraz pytanie. Jak to obejść?? (pomijając fakt aby wymienić komputer na lepszy z dozylionem gigów...  )

Czy można zrobić taki manewr aby najpierw zestakować klatki w porcjach powiedzmy po 30-40 sztuk a potem zestakować staki? Przejdzie coś takiego czy bez sensu?

 

 

[AdamK]

Czy na pewno chodzi o pamięć RAM? Ja mam też QHY163M i 16GB RAM i nigdy nie miałem takich komunikatów, a bywało, że stackowałem znacznie więcej plików niż podajesz...

Owszem, kiedy zaczyna brakować pamięci na dysku to system zaczyna się buntować i wtedy trzeba jej trochę zwolnić.

 

[Łukasz Czerwiński]

Właśnie mam taki problem z AS i walczę z Księżycem. Szukałem po forum w kwestii AS i zauważyłem, że w Pixinsight też był poruszany w innych wątkach podobny problem pamięci. 

[GrzegorzP]

Poza powyższym - Pix aktualny? Jaki format plików?

[Tayson]

zerknij w manager urzadzen/wydajnosc.

cokolwiek bym nie robil pix nidgy nie wchodzi mi powyzej 10gb ramu. procesory za to szaleja!

[Gość wessel]

Pix wykorzystuje dysk do czasowego przechowywania plików o ile mu się to ustawi w preferencjach. Ja mam tam podpiety SSD i zero problemów. Przechowuje tam .tmp podczas obróbki.

Edytowane 22 Września 2020 przez wessel

[Tayson]

To chyba jest w edit/global preferences albo jedno obok. 

[Gość wessel]

Edit>Global preferences>Directories and network - swap storage directories

[poldip]

Pix wersja 1.8.7. Format plików xsif, po 32MB sztuka. W "swap storage directories" mam c:/users/pawel/appdata/local/temp. Dysk systemowy jest SSD 500gb wolnego 80%.

Przy próbie zestakowania 60 klatek, pix pisze że rezerwuje sobie 12GB, dojeżdża do 23% i wywala error jak na obrazku. Wykres zasobów pokazuje pik "do nieba". Zdarza się że windows pokazuje osobne okno systemowe z ostrzeżeniem że brakuje pamięci.

Natomiast stakowanie 21 klatek (dla przykładu) zużywa "tylko" 5GB i się udaje, co widać na obrazku.

Można się kopać z koniem a można go obejść. Sądzę że jakimś wyjściem jest stakowanie partiami a potem stakowanie staków. Pytanie tylko czy to da efekt końcowy porównywalny ze stakowaniem wszystkich klatek na raz.

[Imar]

Ja też miałem podobny problem w 2018...nie mogłem nic o większej ilości zestakować...skończyło się tak że kupiłem dysk hdd 2tb i wskazałem go jako lokalizacje plików i tego folderu temp.

Działało dość wolno, bo cały proces trwał kilka godzin ale jak najbardziej działało.

Używałem wtedy modułu. Batch preprocesing (jakoś tak się nazywa)

Stackowanie, deyberyzacja, align na gwiazdy itp, łącznie prawie pół dysku zajmowało.

Na same stackowanie to jeśli dobrze pamiętam po 400 gb pochłaniało.

 

Jak zauważyłem działo się to tak przez to że pix z każdą procedurą kopiował sobie fotki kilkukrotnie lub też przerzucał z fits na xifs.

Te pliki xifs były strasznie duże.

A ramu miałem 4 gb.

Ramy masz tak wpięte by działały w dualu?

Edytowane 23 Września 2020 przez Selmak

[Gość wessel]

Paweł, coś jest nie tak w konfiguracji komputera . Ja stackowałem ostatnio po 70 klatek z STLa ( 21 MB sztuka) na stareńkim R540 z 8 MB pamieci, ale z SSD jako SWAP i nie było problemu.

[GrzegorzP]

Pytałem o format plików, ponieważ Pix może czytać pili po kawałku (jeżeli są np. zapisane jako xsif bez kompresji), a czasami musi załadować całość (np. jeżeli działamy bezpośrednio na RAW-ach z aparatu). W tym drugim przypadku zazwyczaj są problemy z pamięcią (temat regularnie wraca na forum Pix-a).  Twojego przypadku nie dotyczy (chyba, że masz kompresję w plikach).  

 

Jak napisał przed chwilą Wessel myślę, że to  problem z konfiguracją. Dzisiaj będę składał 125 plików z FF. Mam i7 16GB RAM i ok. 260GB wolnego na dysku roboczym - to chyba największa porcja danych jaką przerabiałem za jednym podejściem., dam znać jak poszło. Na twoim miejscu spróbowałbym jeszcze tradycyjnej metody z reinstalacją programu.

[poldip]

Update z pola walki.

Pokopałem się nieco z koniem, żeby nie było że łatwo odpuszczam. Włączałem i wyłączałem różne ptaszki, przepiąłem katalog temp na inny, itp. Ostatecznie, jak już wszystko zawiodło zacząłem czytać opisy w opcjach stakowania. 

Odhaczyłem "automatic buffer sizes" i zwiększyłem z defoltowych 16/1024 na 64/4096. Opis sugerował że obniży to wydajność ale umożliwi stakowanie większej ilości materiału.

I bingo !!! 

Cokolwiek ta opcja robi, zrobiła w moim przypadku dobrze i pozwoliła na zestakowanie wszystkich klatek w jednej partii.

 

[GrzegorzP]

Moje 125 plików (28GB) przeszło bez problemów  - zarówno zwykły stack jak i drizzle. Co do opcji "buffer size", to ostatni raz zmieniałem ustawienia na wersji 32-bitowej. W tamtym wypadku przy dużej liczbie plików faktycznie inaczej nie chciało składać. To było tak dawno, że dążyłem o niej zapomnieć :).

[WielkiAtraktor]

Tak ogólnie to "Nieprawidłowy odczyt z adresu 0" to skutek jakiegoś błędu logicznego w programie, może nie mieć nic wspólnego z brakiem dostępnej pamięci.