Jump to content
_Spirit_

PixCore - sztuczne pompowanie bitów?

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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ść?

Edited by Selmak

Share this post


Link to post
Share on other sites

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 ...

Share this post


Link to post
Share on other sites

Dla mnie nie ma sensu. Kropka. 

Jezlie chcesz naukowych danych sprawdź statistic w Pixie. 

  • Like 1

Share this post


Link to post
Share on other sites
2 godziny temu, _Spirit_ napisał:

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

 

Share this post


Link to post
Share on other sites

Tak 

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

 

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Nie rozumiem o który etap pytasz. 

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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).

  • Like 1

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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. 

 

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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 :D 

 

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 :P 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 :flirt:

Edited by Krzychoo226
  • Like 3

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.