pixinsight PixCore - sztuczne pompowanie bitów?

[_Spirit_]

Pytanie. 

Czy stosowanie formatu Pixa czyli 32bit  ma sens? Jeśli tak to dlaczego? Jeśli nie to czy można skonfigurować soft tak aby zapisywałam swój format do 16bit?

[Imar]

chyba nie..z 16 bitów nie zrobisz prawdziwych 32 bit jeśli takie z matrycy nie zeszły.

Z 720p nie zrobisz prawdziwego 1080p jeśli nie było takie od początku.

Sztuczne podnoszenie rozmiaru pliku.

Tak myślę na chłopski rozum a sam unikam jak mogę 32 bit.

Ja też dołączam się do pytania o ten format bo w każdym module pixa mam możliwość zapisu klatek w 16 bitach ale przy deyberyzacji nie mogę..jest do wyboru tylko 32 bit, da się to obejść?

Edytowane 26 Października 2019 przez Selmak

[_Spirit_]

No właśnie. Nie przeszkadzało by mi to ale miejsce na dysku maleje. 32bity to 64mb na jedną klatkę z ASI1600 x 200 lub 300 ...

[Tayson]

Dla mnie nie ma sensu. Kropka. 

Jezlie chcesz naukowych danych sprawdź statistic w Pixie. 

[_Spirit_]

2 godziny temu, _Spirit_ napisał:

Jeśli nie to czy można skonfigurować soft tak aby zapisywałam swój format do 16bit?

 

[Tayson]

Tak 

Plik zapisz jako i zmieniasz interesujące Cię parametry.

 

Chyba że masz coś innego na myśli.... 

[_Spirit_]

8 minut temu, Tayson napisał:

Plik zapisz jako i zmieniasz interesujące Cię parametry.

Nie o to mi chodzi. Chciałbym żeby przy pprocesingu zapisywał format 16bit a nie 32.

[Tayson]

Nie rozumiem o który etap pytasz. 

[Krzychoo226]

Oczywiście, że ma sens. Średnia dwóch 16 bitowych plików, jeżeli nie chcemy tracić precyzji, ma więcej niż 16 bitów. Potem pastwimy się nad stackiem całą masą przekształceń matematycznych, wszystko to precyzyjniej będzie działało na 32 bitach, bez odcinania ułamków za każdym razem.

[Gość wessel]

Jest jeszcze jedna ważna rzecz. Cały processing Pixa jest optymalizowany pod format .xisf i 32 bity. Tak twierdzi Juan a on chyba wie

[Adam_Jesion]

Jeden plik ma faktycznie 16 bitów (lub mniej), ale kilka zestackowanych i numerycznie przekształconych plików ma znacznie więcej niż 16 bitów. Po co to tracić konwertując go z powrotem do 16 bitów? 16 bitów powinien mieć plik, który eksportujemy jako gotowe zdjęcie TIFF (np. do galerii, druku, etc.), ale edycyjny oryginał powinien zostać jak najgłębszy.

 

9 godzin temu, Selmak napisał:

Z 720p nie zrobisz prawdziwego 1080p jeśli nie było takie od początku.

Twierdzenie jest prawdziwe tylko dla pojedynczego zdjęcia. Jeżeli masz wiele zdjęć 720p, to spokojnie możesz uzyskać z nich większą rozdzielczość niż 720p. W astrofotografii mamy dokładnie taką sytuację, czyli używamy więcej niż 1 zdjęcie (subekspozycje). Dlatego obróbkę robimy w większej rozdzielczości (drizzle), oraz "głębszych" plikach (32 bity).

[_Spirit_]

Nie o to mi chodzi

Rozumiem dlaczego wynikowy plik - stack ma 32 bity.  Chodzi mi o cały proces pprocesingu, kalibracji, alignacji, normalizacji. Tam pracujemy na pojedynczych plikach i raczej do zawartego w nich sygnału nic nie jest więcej dodawane.

Ale ok. Przyjmuję że tak jest i koniec kropka.

 

[Tayson]

Panowie czegoś nie łapie. 

Zakładam że większość z Nas stackuje mediana lub average (to również poniekąd jest mediana), to jak operacje na poszczególnych pixelach mogą potrzebować 32bitow? 

 

Moje rozumowanie. 

--> Pierwszy sub, pierwszy pixel wartość wartość 20k adu

--> Drugi sub, pierwszy pixel wartość 25k adu. 

Średnia 20+25=45/2=22.5

 

Po co więc 32 bity skoro bez problemu mieścimy się w 16? Gdyby stackowac suma to oczywiście 32 niezbędne inaczej jakoś tego nie czuje. 

 

[MateuszW]

2 godziny temu, Adam_Jesion napisał:

Jeden plik ma faktycznie 16 bitów (lub mniej), ale kilka zestackowanych i numerycznie przekształconych plików ma znacznie więcej niż 16 bitów

Moim zdaniem to tylko połowa kwestii. Zgadzam się, że po zestackowaniu plików 16 bit otrzymujemy więcej bitów i zapis do 32 ma sens. Ale już po wyciągnięciu zdjęcia moim zdaniem możemy śmiało wrócić do 16 bitwy. Argumentuje to tym, że finalnie zdjęcie wyświetlane na monitorze będzie potrzebować tylko 8 bit, więc obrabiając w 16 mamy spory zapas. A po wyciąganiu już nie robimy tak mocnych operacji, które by się nie mieściły w "zapasie", który mamy. 

Ja przynajmniej tak zawsze robię, że po wstępnym wyciągnięciu operuję już tylko na 16 bit i nigdy nie dostrzegłem braku płynności przejść tonalnych na finalny zdjęciu. 

[Krzychoo226]

2 godziny temu, _Spirit_ napisał:

Nie o to mi chodzi

Rozumiem dlaczego wynikowy plik - stack ma 32 bity.  Chodzi mi o cały proces pprocesingu, kalibracji, alignacji, normalizacji. Tam pracujemy na pojedynczych plikach i raczej do zawartego w nich sygnału nic nie jest więcej dodawane.

Ale ok. Przyjmuję że tak jest i koniec kropka.

 

Master bias to średnia z kilkudziesięciu/kilkuset pojedynczych klatek, to samo tyczy się pozostałych klatek kalibracyjnych. Idąc dalej, o ile biasy i darki od zdjęcia się odejmuje to przez flat zdjęcie jest niejako dzielone. Żeby uzmysłowić problem brakujących bitów weź najprostszy biurkowy kalkulator, wpisz dowolna liczbę i podziel kilkanaście razy przez 3, a następnie pomnóż tą sama ilość razy również przez 3. Co uzyskałeś? A to najzwyklejsze dzielenie. Istotne by był to prosty kalkulator biurkowy, bo te systemowe i te w telefonach są już od dawna "idiotoodporne" i eksperyment nie wyjdzie.

 

30 minut temu, Tayson napisał:

Panowie czegoś nie łapie. 

Zakładam że większość z Nas stackuje mediana lub average (to również poniekąd jest mediana), to jak operacje na poszczególnych pixelach mogą potrzebować 32bitow? 

 

Moje rozumowanie. 

--> Pierwszy sub, pierwszy pixel wartość wartość 20k adu

--> Drugi sub, pierwszy pixel wartość 25k adu. 

Średnia 20+25=45/2=22.5

 

Po co więc 32 bity skoro bez problemu mieścimy się w 16? Gdyby stackowac suma to oczywiście 32 niezbędne inaczej jakoś tego nie czuje. 

 

Średnia nie ma zbyt wiele wspólnego z medianą, wystarczy spojrzeć na średnią zarobków w Polsce  

 

Wybrałeś ekstremalnie prosty przykład idealnie pasujący do twojej tezy, mógłbyś zostać politykiem Piksele nie mają takich ładnych wartości, powiedzmy piksel A ma 20543, a piksel B 25512. Średnia to 23027,5 i to .5 już się nie zmieści w 16 bitach, potrzebujesz 17. A teraz dodaj 50 subów, 300 biasów, 100 flatów, przemiel to stackowaniem, kilkoma metodami odszumiania, deconvolucją, histogramem itd.

 

Ale ja wiem co Was boli, nie te 32 bity tylko rozmiar tych plików A kto Wam kazał kupować takie wielkie matryce? Mój Atik 414EX ze swoją rozdzielczością 1.4M wychodzi tu obronną ręką i śmieje się jako ostatni

Edytowane 27 Października 2019 przez Krzychoo226

[MateuszW]

21 minut temu, Tayson napisał:

Średnia 20+25=45/2=22.5

 

Po co więc 32 bity skoro bez problemu mieścimy się w 16?

Właśnie dlatego 25,5. Żeby zapisać ta wartość bez strat potrzebujesz już 17 bitów. 32 bity rozum nie jako "rozszerzenie" zakresu ADU w górę, tylko jako zagęszczenie możliwych wartości. Ale jak pisałem wcześniej, uważam że po wyciągnięciu zdjęcia już można zrezygnować z 32 bit. 

[_Spirit_]

6 godzin temu, Krzychoo226 napisał:

rozmiar tych plików

No przecież że tylko o to.

Ale po Twoim objaśnieniu 5+-5 itd. zostaję w 32bitach. Dzięki za objaśnienie.