Behlur_Olderys

Nie zgadzam się. Zobacz, ile pięknych rzeczy jest w tym szerokim kadrze. Gdyby ktoś zrobił fotkę w tamtym rejonie z naświetlaniem kilku godzin, zdjęcie byłoby z pewnością bardzo estetyczne

http://astropolis.pl/topic/37824-virgo-wide/?do=findComment&comment=650293- chyba jedyny strzał w tą okolicę na naszym forum. Wstyd!

Na tym zdjęciu można odnaleźć miejsce, gdzie powinien być najbliższy (najjaśniejszy?) kwazar 3C 273. Nieopodal galaktyczek NGC4527 i 4536... Super!

A co to za galaktyczka żółta, lewy górny róg (bardziej górny niż lewy ) ? ps zdjęcie super, aż trudno uwierzyć, że tak wygląda niebo nocą...

Jest to zjawisko relatywistyczne - gdyby prędkości dodawały się "normalnie" czyli po galileuszowsku, to nie byłoby tego problemu. Tymczasem do prędkości światła nic się nie dodaje, jest stała w każdym układzie. Najprościej sobie to wyobrazić w przypadku, gdy dżet świeci prosto na nas i porusza się praktycznie z prędkością c (powiedzmy, bez jedynki na dziesiątym miejscu po przecinku). Gdyby prędkości dodawały się 'normalnie' to światło wyemitowane z dżetu pędzącego prosto na nas miałoby prędkość praktycznie 2c. A tymczasem transformacja Lorentza mówi, że zawsze będzie to wartość c, więc względem dżetu światło z niego wyemitowane będzie praktycznie stało w miejscu, poruszało się z nim równolegle niemal z tą samą prędkością. Dlatego dla obserwatora w takim przypadku (relatwistyczny dżet na wprost) światło wyemitowane na początku i na końcu dżeta dojdzie do obserwatora w tym samym momencie, a nie po czasie równym długości dżeta podzielonej przez jego prędkość. Ta różnica jest przyczyną pozornej "nadświetlności". W odpowiednich warunkach perspektywistycznych, oczywiście, ale nie bez szczególnej teorii względności. Pozdrawiam!

Dżentelmeni o piratach nie rozmawiają. Jeśli używasz takiego oprogramowania, to jakakolwiek prośba o pomoc mija się z celem. Nie działający poprawnie system i brak wsparcia to właśnie cena, jaką płaci się za kradzież.

Za 2500 to można spokojnie Canona np. 500D i jeszcze jakies fajne szkło kupić... ja bym się nawet nie zastanawiał, ale ja wiem, czego chcę

1. Start->uruchom. Wpisz cmd. Ukaże się konsola. W tej konsoli wpisz ipconfig. Powinno się wyświetlić na dłużej.

Osobiście polecam 700d do fotografii dziennej i nocnej. Oczywiście, nie jestem w żadnym wypadku profesjonalistą, ale wydaje mi się, że jest to konstrukcja na tyle nowa, że będzie miała większość ciekawych udogodnień przydatnych do dziennej fotografii, jak wszystkie zalety Canona cenione w astrofoto. Nie ma tu jakiegoś wielkiego wskazania na ten konkretny model: 750d pewnie też jest ok, słyszałem też dużo dobrego o 100d oraz 1000d. Nie wiem, czy są jakieś znaczące różnice między tymi modelami, o ile się nie jest super wybrednym specjalistą.

_Spirit_, po co się zaraz tak unosić Poleciłem SC dlatego, że warto chyba spróbować, zanim się zdecydujesz na reinstalkę. On ma sporo funkcji diagnostycznych. A instalowanie innego antyvira przy podejrzeniu infekcji to leczenie chorego na grypę za pomocą szczepionki wciąż podtrzymuję zdanie, że najlepsze wyjście to reinstalka, a potem dobry antywirus plus higiena pracy: czysta instalka, kopia zapasowa, sprawdzony soft z dobrych źródeł i broń Boże żadnych piratów!

Pewnie wszystko zależy od dokładności ustawienia na biegun....

+1 dla reinstalacji Windowsa. Polecane raz na pół roku. Ewentualnie, zanim to zrobisz, warto skorzystać z system cleanera czy tym podobnych programów do czyszczenia systemu. Czasami pomagają.

Loki, jeszcze się nie nauczyłeś? Teorie z tego działu nigdy nie mają "jednoznacznego rozstrzygnięcia" Z każdą próbą tegoż schodzą tylko coraz głębiej w spisek i paranoję.

Dodałbym do tego zestawienia Fastron:)

Piękne! To dobra motywacja dla mnie, żeby inwestować w montaż... btw: muszę założyć pająk na obiektyw, bo te spajki dodają +10 do wdzięku

http://www.100fps.com/file_sizes_of_lossless_compression.htm Porównanie bezstratnych kompresji wideo. HuffyUV jest na tyle szybki, że na 416MHz single core procesorze Celeron ma throughput ok. 38MB/s. (za angielską wiki). http://www.animemusicvideos.org/guides/avtechbeta/video4.htm Dodatkowy plus dla klona HuffyUV z obsługą multicore procesorów. Pewnie wymagałoby to tak czy siak osobnej maszyny do akwizycji i osobnej do sterowania montażem... Ale na pewno zmniejszyłoby zmartwienia związane z miejscem na dysku. Może będę miał jeszcze dziś czas to sprawdzę co się stanie, jak zawinę część moich zdjęć tym algorytmem - jak długo trwa kompresja i ile waży wynikowy plik. Pozdrawiam!

Zamiana ciągu 1111111111111111111111111111111111111111 na 40x1 jest bezstratną kompresją - właśnie skompresowałem 40 bajtów do 4, poziom kompresji = 90% Zasadniczo jest mnóstwo algorytmów kompresji bezstratnej, polecam przeszukać internety Notabene, choć to trochę inny kaliber: LHC też nie zgrywa wszystkiego jak leci, bo tam są terabajty na sekundę. Specjalne triggery odfiltrowują wydarzenia w locie i efektywnie zapisywany jest tylko ułamek "ciekawych" zdarzeń. Osobiście uważam, że osobny sprzęt, najlepiej dedykowany, powinien zajmować się tylko i wyłącznie akwizycją z kamery plus ewentualnie pre-processing, a osobny, klasy pecet- wszystkim innym. To, o czym mówisz, Hansie, jako optimum, to dla mnie minimum Są dwie skrajności: robić wszystko w locie (nie da rady, za mało mocy/pamięci) albo robić wszystko po akwizycji (nie ma mowy: za mało dysku). Optimum to własnie to, o czym mówię: kilka niezbędnych rzeczy dołożyć in-flight żeby zminimalizować zużycie storage'u, a resztą zająć się na spokojnie bez inwestowania w 10TB dyski SSD. Nie chce mi się zresztą wierzyć, żeby guiding czy sterowanie montażem to były jakieś pamięciożerne kolosy, chyba że są kiepsko napisane. Może pora przerzucić się na Linuxa? Wydaje mi się, że maszynka która ogarnie wszystko (oprócz akwizycji) powinna kosztować jakieś 300-400zł, bo tyle kosztują używane laptopy.

Minuta materiału to kilka GB? omg 160 MB / s.... Proponuję przedwstępne filtrowanie materiału, może nie potrzeba zawsze całej klatki (wyciąć rogi czy coś? )? Odpalenie zaraz po akwizycji prostego programiku "obcinającego" zdjęcie lub dokonującego jakiejś bezstratnej kompresji powinno dać się zrobić w locie. W końcu mówimy o sygnale bardzo słabo zmiennym w czasie. Przyda się oczywiście dużo RAMu i dobry algorytm

Jeśli przetwarzanie jednej klatki dużo zajmuje, a jest to proces niezależny od drugiej klatki, to może warto pomyśleć nad przetwarzaniem w locie, podczas akwizycji? Czy jest to wykonalne? A może przetwarzanie jednej klatki trwa dużo dłużej, niż jej akwizycja więc i tak wiele to nie da? Powiem Wam tak: jeśli mielibyście zwiększyć czułość przez długotrwałą (kilkudniową)obróbkę, jakkolwiek skomplikowaną, to jest to warte zachodu - prąd jest tańszy niż nowy sprzęt:)

Kajetan - wygląda dosyć czarnobiało... Rozumiem, że stackowanie DSS? PixInsight LE nie czyta (chyba) domyślnie 32bitowych stacków z DSS. Można chyba czymkolwiek zapisać stacka z 32b na 16b i wtedy już pixinsight daje radę. Przynajmniej ja tak robię Spróbowałbym jeszcze raz zestackować, może z większą selekcją (50% najlepszych klatek)? Ponad 1000 sekund naświetlania, to jednak jest sporo materiału jak na statyw

Tak, wiertarka stołowa to by było to:) od biedy prosty frez można tym zrobić chyba... Do nakrętki tej M8 masz coś przymocowane, żeby się mogła swobodnie obracać na ramieniu czy jak to mocujesz? A sprzęgło jakieś polecasz? Ja myślałem o takim elastycznym sprzęgiełku dociskanym imbusowymi śrubkami, ale długo mi zeszło, zanim znalazłem w necie, że takie coś to się nazywa sprzęgło:)

Może nie zmierzyliśmy i nie zważyliśmy wszystkiego, ale zadajemy coraz bardziej szczegółowe pytania i na wiele mamy już odpowiedzi. Kiedyś ludzie uważali, że Ziemia jest płaska, a gwiazdy są przylepione do nieboskłonu. Czy uznanie istnienia galaktyk i układu słonecznego, albo poznanie natury kwantowej mikroświata to pycha i arogancja? Człowiek z natury chce sięgać dalej, to nie arogancja. To ambicja.

Na dole? Z boku? Nie do końca łapię tą topografię, przez co w ogóle nie zrozumiałem pierwszych akapitów. Myślałem że w nożycach, na przykładzie astrowalkera, silnik krokowy, sprzęgło, śruba, wodzik i nakrętka są wszystkie ustawione współosiowo, w jednej płaszczyznie, na jednym elemencie konstrukcji?

Ostrą końcówką, tj. końcówką śruby, czy tak? Ja zakładałem okrągłą nakrętkę, ale chyba to było zbyt naiwne, bo jak sprawdzałem ostatnio owocowało to bardzo wyraźnym błędęm prowadzenia o okresie - o dziwo - 1 minuty. Pewnie też i śruba nie była idealnie prostopadle włożona, będę to męczył przez zimne, jesienne wieczory Co do nożycowego - z jednej strony śruba jest zamocowana do silnika krokowego, a z drugiej - do jakiegoś stopera na końcu. Rozumiem, że problemem jest przemieszczanie się śruby jakby wzdłuż osi obrotu? W sensie - że trzeba śrubę umocować jak najbardziej "na ścisk" żeby się nie ruszała? Ja wychodziłem z założenia, że może przez pierwsze kilka sekund być problem, ale później to już chyba się samo "dociśnie", czy to też naiwne myślenie? 0.01mm to bardzo wyśrubowana (hehe!) dokładność...

Mój program w domyśle bazuje na założeniu, że jedyna zmienna, której potrzebuję do ruchu montażem, to odstęp pomiędzy kolejnymi krokami silnika krokowego. Każdy krok silnika to pewne drobne przesunięcie ramienia o stałą odległość dy. Zakładając, że odstęp czasowy dt jest na tyle mały, że można pominąć wyrazy większe niż liniowe wychodzą mi bardzo ładne funkcje odstępu pomiędzy krokami (dt) w zależności od czasu, jaki montaż już działa (zakładam bowiem, że prędkość kątowa ramienia jest równa prędkości kątowej Ziemi = omega). Dzięki temu, po drobnych przekształceniach wychodzi prosty wzór: delta t = dy * cos(omega*t)^2 / (R * omega) dla koziołka ze śrubą prostopadłą do ramienia delta t = dy / (R * omega * cos(omega * t / 2 )) dla napędu nożycowego Moim zdaniem wzory są na tyle proste, że można je obliczać na bieżąco w arduino. Jedyna zmienna to czas działania. Pewien problem, to że odstęp pomiędzy krokami trzeba podać jako całkowitą liczbę milisekund, a wyniki wychodzą jako liczby zmiennoprzecinkowe. Ale to akurat można łatwiutko obejść zapisując na boku resztę dziesiętną i dodając ją do każdego następnego t. Drugi problem to skończony czas na obliczenia - tutaj trzeba byłoby skorzystać z dokładnych funkcji mierzenia czasu zamiast prostego delay. Jak tylko znajdę więcej czasu to przedstawię swoją wersję programu, jakkolwiek czysto teoretyczną, bo ostatnio rozwaliłem koziołka aby transformować go do wersji nożycowej. Efekt: zostałem z niczym