Derin gökyüzü görüntüleme · Teknik rehber
30 saniyede drizzle
- Sorun: Pikselleriniz yıldız görüntüsünden büyükse, teleskobunuzun topladığı detay sensöre sığmıyor. Buna yetersiz örnekleme (undersampling) denir. Yıldızlar kare kare, köşeli görünür.
- Çözüm: Her karede gökyüzünü piksel kesri kadar kaymış olarak kaydedin. Her kare, sahneyi biraz farklı bir noktadan örnekler. Drizzle bu örnekleri daha ince bir ızgarada birleştirip kaybolan detayı geri kazanır.
- Şart: Kareler arasında rastgele kaydırma (dithering) olmalı. PHD2 bunu yapar. Dither yoksa drizzle işe yaramaz — hatta çıktıda delikler bırakır.
- Bedeli: Dosya boyutu ölçeğin karesi kadar artar (2× = 4 kat), gürültü artar ve komşu pikseller korelasyonlu hale gelir. SNR ölçüm araçları drizzle'lı görüntüde yalan söyler.
- Ne zaman? Kayıtlı karelerinizde yıldız FWHM < 2 piksel ise drizzle deneyin. FWHM 3 piksel ve üzeriyse drizzle size hiçbir şey kazandırmaz, sadece dosyanızı şişirir.
Forumlarda drizzle kadar tartışılan az konu var. Biri "her zaman aç, bedava çözünürlük" diyor, öbürü "sakın açma, sadece gürültü getirir" diyor. İkisi de yanılıyor, çünkü ikisi de aynı hatayı yapıyor: drizzle'ı herkese uyan bir ayar sanıyorlar. Oysa drizzle bir ilaç gibi. Belirli bir derde iyi gelir. O dert sizde yoksa hiçbir işe yaramaz, yan etkileri yerinde durur.
Sıra şöyle: önce derdin ne olduğuna bakacağız, sonra drizzle'ın onu nasıl iyileştirdiğine, sonra da çalışması için şart olan tek şeye — kareler arasında teleskobu birazcık kaydırmaya. Sonunda kendi ekipmanınızın rakamlarını girip "bana lazım mı?" sorusuna cevap alabileceğiniz hesaplayıcılar var. Formül ezberlemeniz gerekmiyor; hesabı onlar yapıyor.
BÖLÜM 1
Temeller: piksel, görüntü ölçeği ve FWHM
Drizzle'ın ne yaptığını anlamak için önce kameranızın gökyüzünü nasıl parçalara ayırdığını görmek gerekiyor. Üç fikir yeter, üçü de gündelik hayattan tanıdık.
Piksel bir nokta değil, bir kova
Yağmuru ölçmek için bahçeye dizilmiş kovaları düşünün. Her kova ağzına düşen suyu toplar ve size tek bir sayı verir: "bu kadar yağmış". Kovanın içinde suyun sağa mı sola mı daha çok düştüğünü asla öğrenemezsiniz. Sensörünüzün pikselleri de tam olarak böyle. Her piksel kendi alanına düşen ışığı toplayıp tek bir sayı üretir; o alanın içinde ışığın nasıl dağıldığı kaydedilmez. Drizzle'ın bütün mantığı bu tek cümleye dayanıyor.
İkinci fikir: yıldızlar görüntünüzde nokta değil. Teleskop ne kadar iyi olursa olsun, araya giren hava ve optiğin kendi sınırları yüzünden her yıldız küçük bir ışık lekesine dönüşür. Bu lekenin ne kadar şişkin olduğunu tek bir sayıyla anlatırız; astronomlar ona FWHM der. İsmi önemli değil, akılda tutulacak şey şu: leke kaç piksele yayılıyor? Drizzle kararının tamamı bu sayıya bakar.
Görüntü ölçeği: bir piksel gökyüzünün ne kadarını görür?
Bir pikselin gökyüzünde kapladığı açısal genişliğe görüntü ölçeği (image scale / sampling) denir, birimi yay saniyesi bölü piksel (″/px). Formülü basittir:
Üçüncü fikir: aynı kamera, farklı teleskoplarda farklı davranır. Kısa odaklı bir teleskopta her piksel gökyüzünün geniş bir parçasına bakar, uzun odaklıda dar bir parçasına. Yani "pikselim büyük mü küçük mü" sorusunun cevabı kameranızda değil, kamerayla teleskobun birlikteliğinde saklı. Aynı kamerayı 400 mm'lik bir teleskoba takarsanız her piksel yaklaşık 2 yay saniyesi görür; 2000 mm'lik bir teleskoba takarsanız beşte biri kadarını. Bu sayıyı elle hesaplamanız gerekmiyor — az aşağıdaki hesaplayıcı sizin için yapıyor.
Sihirli oran: FWHM'nin kaç piksele düştüğü
Asıl belirleyici sayı, ne ölçek ne de FWHM tek başınadır — ikisinin oranıdır:
Scripts > Image Analysis > FWHMEccentricity, Siril'de kare istatistikleri, ASTAP'ta HFD/FWHM sütunu.Burada ters gibi görünen bir şey var. Lekenin genişliği her gece aynı değildir: hava sakinse yıldızlar daha derli toplu çıkar. Kulağa iyi haber gibi geliyor, öyle de — ama bir yan etkisi var. Leke küçüldükçe daha az piksele düşer, yani en iyi gecelerinizde kameranız detayı yakalamakta en çok zorlanır. Deneyimli kullanıcıların "en iyi gecelerde drizzle daha çok işe yarıyor" demesinin sebebi tam olarak bu.
Hesaplayıcı 1 — Örnekleme durumunuz
Kameranızın piksel boyutunu, teleskobunuzun odak uzaklığını ve tipik seeing'inizi girin.
BÖLÜM 2
Örnekleme: az mı, tam mı, çok mu?
Bir şeyin şeklini kaydetmek istiyorsanız onu en az iki noktadan ölçmeniz gerekir. Tek ölçüm size sadece "bir şey var" der, şeklini anlatmaz. Bu kural ses kaydından fotoğrafa kadar her yerde geçerli; mühendisler ona Nyquist kriteri diyor ama adını bilmek zorunda değilsiniz. Bize düşen karşılığı basit: bir yıldızın ışık lekesi en az iki piksele yayılmalı. Daha azına sığıyorsa şekli kaydedilmiyor demektir ve yıldız yuvarlak değil, köşeli çıkar.
| Kayıtlı karede FWHM | Durum | Tipik sebep | Drizzle kararı |
|---|---|---|---|
| < 1.5 px | Ağır yetersiz örnekleme | Fotoğraf lensi, kısa odaklı apo, büyük piksel | 2× drizzle güçlü aday |
| 1.5 – 2.0 px | Yetersiz örnekleme | Kısa odak + orta piksel | 2× drizzle dene |
| 2.0 – 3.0 px | Doğru örnekleme | Dengeli kurulum | Genelde gereksiz; 1× CFA drizzle mantıklı |
| > 3.0 px | Aşırı örnekleme | Uzun odak, küçük piksel, vasat seeing | Drizzle yapmayın |
Forumlarda sık duyulan bir kestirme var: "2″/px üstündeysen drizzle yap." Bu kural havayı hesaba katmadığı için yanıltıcı. Havanın çalkantılı olduğu bir gecede yıldızlar zaten şişer ve rahatça birkaç piksele yayılır — o gece drizzle'a ihtiyacınız yoktur. Bakılacak yer ekipmanın kutusundaki rakam değil, o gece çektiğiniz karelerde yıldızların gerçekte kaç piksele yayıldığı. Bu sayıyı Siril, PixInsight ve ASTAP dâhil hemen her program size söyler.
Bu konuda çarpıcı bir örnek var. ASTAP'ın geliştiricisi Han Kleijn, drizzle desteğini programından tamamen çıkardı. Gerekçesi şuydu: "Bugünlerde piksellerinin çok büyük olduğu ve drizzle gerektiren amatörler olduğuna dair bir belirti görmüyorum. Çoğunun görüntüsü, küçük piksel boyutları ve göreli kötü seeing yüzünden zaten fazlasıyla ayrıntılı." Yani bugünün kameralarında sorun çoğu zaman ters yönde. "Her zaman aç" tavsiyesinin neden kötü bir tavsiye olduğunu bundan iyi anlatan bir şey yok.
BÖLÜM 3
Drizzle nedir ve nasıl çalışır?
Drizzle 1998'de, Hubble Uzay Teleskobu'nun o meşhur "derin alan" çekimleri için bulundu. Hubble'ın o günkü kamerası da bizim bugün yaşadığımız dertten muzdaripti: optik, sensörün kaydedebileceğinden fazla detay üretiyordu ve fark boşa gidiyordu. Andrew Fruchter ile Richard Hook, gökyüzüne yeniden çıkmadan, ellerindeki kareleri daha akıllı birleştirerek o detayın bir kısmını geri almanın yolunu buldu. Uzun adı "değişken pikselli doğrusal yeniden yapılandırma"; kimse öyle demiyor.
Adı da buradan geliyor: İngilizcede drizzle "çiselemek" demek. Her karedeki her piksel, küçük bir damla gibi, daha ince gözlü yeni bir ızgaranın üzerine çiseleniyor. Kovalar sabit dururken yağmurun her seferinde biraz farklı yere düşmesi gibi.
Üç adımda mekanizma
- Küçült (shrink). Her giriş pikselini merkezinden itibaren küçültün. Küçültme oranı pixfrac parametresidir (PixInsight'ta Drop shrink, APP'de drop size). pixfrac = 0.5 ise, piksel kenar uzunluğunun yarısı kadar bir "damla" elde edersiniz.
- Yerleştir (map). Kaydın (registration) verdiği geometrik dönüşümü kullanarak damlayı çıktı ızgarası üzerindeki gerçek yerine taşıyın. Çıktı ızgarası daha ince olabilir (2× drizzle = yarı boyutta çıktı pikselleri).
- Dağıt (distribute). Damlanın taşıdığı ışığı, örttüğü çıktı piksellerine örtüşme alanıyla orantılı olarak paylaştırın. Her çıktı pikseli aynı zamanda ne kadar "ağırlık" aldığını da biriktirir.
Bunu bütün kareler için tekrarlayın. Sonunda her yeni piksel, üstüne düşen bütün damlaların ortalamasını taşır. Hepsi bu.
Meraklısına: perde arkasındaki iki satır
Bu bölümü atlayabilirsiniz; drizzle'ı kullanmak için gerekmiyor. Merak edenler için asıl işi yapan hesap şu kadar basit: her damla, üstüne düştüğü her yeni piksele ne kadar örtüştüyse o kadar katkı yapar ve sonuçta ağırlıklı bir ortalama alınır. Fruchter ile Hook'un makalesindeki iki satır tam olarak bunu söylüyor:
Iyeni = ( d · a · w · s² + Ieski · Weski ) ÷ Wyeni
Yani özeti: ağırlıklı ortalama, ağırlık da damlanın ne kadarının o pikselin üstüne düştüğü. Bu sadelik bir yan fayda getiriyor: drizzle parlaklıkları bozmuyor. Bir yıldızın görüntüdeki toplam ışığı ölçülebilir kalıyor — bilimsel çalışmalarda kullanılabilmesinin sebebi bu.
İki uç nokta: interlacing ve shift-and-add
Damlanın büyüklüğünü değiştirdiğinizde drizzle, kendinden önceki iki eski yöntemin arasında gidip geliyor. Damlayı iyice küçültürseniz eski "interlacing" yöntemine, damlayı hiç küçültmezseniz "shift-and-add" yöntemine dönüşüyor. Fruchter ile Hook bunu şöyle yazmış: "Interlacing, pixfrac → 0.0 limitinde drizzle'a eşdeğerdir; shift-and-add ise pixfrac = 1.0'a eşdeğerdir." Aradaki her değer, iki uç arasında bir denge.
Photoshop'ta bir görüntüyü iki katına büyüttüğünüzde program aradaki pikselleri komşularına bakıp uydurur. Drizzle bunu yapmaz: her yeni pikselin değeri, oraya gerçekten düşmüş ölçülmüş ışıktan gelir. Hiçbir kare o bölgeye denk gelmemişse, drizzle o pikseli boş bırakır (delik). Bu, drizzle'ın hem gücü hem de dithering'e bağımlılığının sebebidir.
BÖLÜM 4
Canlı simülatör: drizzle'ı kendiniz çalıştırın
Aşağıdaki simülatör anlatılanı okuduğunuz sayfada, gerçekten çalıştırıyor. Yapay bir gökyüzü kuruyor, onu detayı taşıyamayan bir kamerayla farklı konumlardan çekiyor ve sonuçları üç ayrı yöntemle birleştiriyor. Düğmelerle oynayın — drizzle'ın ne yaptığını on cümleden daha iyi anlatır.
Şunu mutlaka deneyin: "Dithering" anahtarını kapatın ve kare sayısını sonuna kadar artırın. Hiçbir şeyin düzelmediğini, hatta çıktının delik deşik olduğunu göreceksiniz. Sonra anahtarı açın, kare sayısını değiştirmeden farka bakın. Bu yazıdan tek bir şey aklınızda kalacaksa, o şey bu.
Drizzle simülatörü
Ayarları değiştirin, dört panel anlık olarak yeniden hesaplanır.
Sonsuz çözünürlüklü referans
Kameranızın gördüğü
Enterpolasyonla ölçeklenmiş
Aynı veriden yeniden yapılandırma
1. Dithering kapalıyken kare sayısını 80'e çıkarmak drizzle'ı kurtarmaz — gürültü azalır ama çözünürlük artmaz. Yeni örnekleme fazı gelmediği için yeni bilgi de gelmiyor.
2. "Sadece tam piksel kayma" seçeneği de işe yaramaz. Kayma kesirli olmalı.
3. Ölçeği 3×, pixfrac'i 0.10, kare sayısını 3 yapın: çıktının %70'i boş piksel olur. Şimdi kare sayısını yavaşça artırın — delikler tek tek kapanır. İşte pixfrac ile kare sayısı arasındaki ilişki tam olarak bu: damla küçüldükçe daha çok kareye ihtiyacınız var.
4. Örneklemeyi "4.2 px — aşırı" yapın: drizzle paneli klasik yığından farksız hale gelir. Kazanılacak bilgi kalmamıştır.
BÖLÜM 5
pixfrac, ölçek ve gürültü korelasyonu
Drizzle'ın en yanlış anlaşılan yanı gürültüye etkisi. "Drizzle gürültüyü artırır" cümlesi doğru ama eksik — asıl mesele gürültünün miktarı değil, karakteri.
Neden komşu pikseller birbirine benzer hale gelir
Bir damla birden fazla çıktı pikselini örtüyorsa (ki genelde örter), aynı giriş pikselinin gürültüsü o çıktı piksellerinin hepsine dağılır. Sonuç: komşu çıktı pikselleri artık bağımsız değil, korelasyonlu. Bu, piksel-piksel gürültü ölçen araçların yanılmasına yol açar — çünkü komşular birbirine benzediği için ölçülen "gürültü" gerçekte olduğundan küçük çıkar.
Bu etkinin ne kadar olduğu hesaplanabiliyor. Aşağıdaki iki satır meraklısı için; sonucu okumak yeterli.
r ≥ 1 ise: R = r ÷ ( 1 − 1/(3r) )
r ≤ 1 ise: R = 1 ÷ ( 1 − r/3 )
Sonuç şu: damla küçüldükçe bu yan etki azalıyor. Buradan "öyleyse damlayı iyice küçültelim" sonucu çıkmıyor — çıkarsa felaket olur, çünkü minik damlalar yeni ızgaranın çoğunu boş bırakır. Yani bu sayı tek başına peşine düşülecek bir hedef değil, ödediğiniz bedeli gösteren bir gösterge. Kararı ona bakarak değil, bir sayı olarak görmeyin; ödediğiniz bedelin büyüklüğünü gösteren bir gösterge olarak görün.
r ile birlikte tekdüze artar: damla küçüldükçe gürültü korelasyonu azalır. Ama bu tek başına "küçük pixfrac daha iyi" demek değildir — damla küçüldükçe çıktı ızgarasında delik bırakma riski artar. İşaretli halkalar r = 1 noktalarıdır: damlanın tam olarak bir çıktı pikseli boyutunda olduğu yer. Siril'in "piksel kesri kabaca drizzle ölçeğinin tersi olmalı" kuralı tam olarak bu noktayı hedefler — kabul edilebilir korelasyon ile güvenli kapsama arasındaki denge noktası.| Ölçek | pixfrac | r | R | Not |
|---|---|---|---|---|
| 1× | 1.0 | 1.00 | 1.50 | Denge noktası. CFA drizzle için standart ayar |
| 2× | 0.5 | 1.00 | 1.50 | Denge noktası. Siril'in önerdiği başlangıç |
| 2× | 0.6 | 1.20 | 1.66 | Fruchter & Hook'un makalede örnek verdiği tipik değerler |
| 2× | 0.9 | 1.80 | 2.21 | PixInsight varsayılanı — belirgin şekilde denge noktasının üstünde |
| 2× | 1.0 | 2.00 | 2.40 | Shift-and-add'e eşdeğer; çözünürlük kazancı büyük ölçüde kayboluyor |
| 3× | 0.33 | 0.99 | 1.49 | 3× için denge noktası — ama çok kare ister |
| 3× | 1.0 | 3.00 | 3.38 | Yapmayın |
| 2× | 0.2 | 0.40 | 1.15 | Korelasyon çok düşük ama delik dolu çıktı — R tek başına karar vermez |
Hesaplayıcı 2 — Kendi ayarınızın R değeri
Yazılımınızda gireceğiniz değerleri seçin, teorik gürültü korelasyonunu ve dosya maliyetini görün.
Drizzle çıktısını bir SNR/gürültü betiğiyle ölçüp "vay be, gürültü azalmış" derseniz yanılırsınız. Bu araçlar komşu piksel farklarına bakar; drizzle komşuları korele ettiği için ölçüm gerçeği R kat iyimser gösterir. PixInsight varsayılanlarında (2× / 0.9) bu 2.2 kat demektir. Drizzle'lı ve drizzle'sız iki yığını sayısal SNR ile karşılaştırmak geçersiz bir karşılaştırmadır; göz kararı ve yıldız FWHM ölçümü daha güvenilirdir.
Peki gürültü gerçekten artıyor mu?
Evet, artıyor. Aynı miktarda ışığı dört kat fazla piksele bölüyorsunuz; her pikselin payına doğal olarak daha azı düşüyor. AstroPixelProcessor'ın kendi belgesi bunu hiç yumuşatmadan söylüyor: "Drizzle BÜYÜK bir gürültü enjektörüdür" ve "Drizzle her zaman keskinlik ile gürültü arasındaki dengedir."
Ama gürültünün dokusu genelde iyileşir. Drizzle yapılmamış bir yığında gürültü iri ve yumuşak lekeler hâlinde görünür; drizzle'lıda daha ince taneli olur. İnce taneli gürültüyle gürültü azaltma araçları çok daha kolay baş eder. Bazı kullanıcıların "sayılar kötüleşti ama görüntü daha temiz görünüyor" der — ikisi de doğrudur.
Damla boyutunu şuradan başlatın: iki kat büyütüyorsanız 0.5, üç kat büyütüyorsanız 0.33. Sonra çıktıya %100 yakınlaştırıp bakın. Delikler ya da tuhaf hâle desenleri görüyorsanız iki seçeneğiniz var: damlayı biraz büyütün ya da daha çok kare toplayın. Drizzle'ı ayarlamak dediğimiz şey, bu iki seçenek arasındaki tercihten ibaret.
BÖLÜM 6
Dithering: drizzle'ın yakıtı
Dithering kulağa teknik geliyor ama yaptığı şey çok basit: her pozdan sonra teleskobu birkaç piksel kaydırmak. Hepsi bu. Astrofotoğrafçılar bunu yıllardır yapıyor, çoğu da drizzle'la ilgisini bilmeden — çünkü tek başına bile işe yarıyor. Drizzle içinse sadece faydalı değil, şart.
Dithering'in dört işi
| Problem | Nasıl oluşur | Dithering nasıl çözer |
|---|---|---|
| Sabit desen gürültüsü (fixed-pattern noise) |
Sensörün okuma devresinden gelen, her karede aynı piksellerde tekrar eden sütun/satır deseni | Desen sensöre sabit; gökyüzü kayınca hizalama sonrası desen gökyüzüne göre hareket eder ve eleme algoritmaları onu aykırı değer olarak atar |
| Sıcak / ölü pikseller | Kusurlu pikseller her karede aynı yerde parlak/kara nokta üretir | Aynı mekanizma. Etkili eleme için en az ~10 farklı dither pozisyonu gerekir |
| Yürüyen gürültü (walking noise) |
Hafif kutup hizası hatası alanı yavaşça tek yönde sürükler; sıcak pikseller çapraz çizgilere dönüşür ve yığınlama bunları güçlendirir | Rastgele dither, sürüklenmenin düzenliliğini bozar. Bu, dithering'in en görünür faydasıdır |
| Yetersiz örnekleme | Piksel içi detay her karede aynı şekilde kaybolur | Her kare sahneyi farklı bir alt-piksel fazından örnekler; drizzle bu farklı fazları birleştirip detayı geri kazanır |
Alt-piksel faz: drizzle'ın gerçekten ihtiyaç duyduğu şey
"Alt-piksel dithering" lafı çok kişiyi yanlış yola sokuyor. Kaydırmanın bir pikselden küçük olması gerektiği anlamına gelmiyor. Anlatmak istediği şu: kaydırma 7 piksel de olabilir, 7.36 piksel de — önemli olan sondaki küsurat, yani ".36". Her karede o küsurat farklı olsun ve 0 ile 1 arasına iyi yayılsınalı.
Amatör bir kurulumda alt-piksel faz çeşitliliği bedava gelir. Nedeni: PHD2 rastgele bir ondalıklı sayı üretir, rehber kamera ile çekim kamerası arasındaki ölçek oranı neredeyse hiçbir zaman tam sayı değildir ve rehberleme artık hataları da fazladan rastgelelik katar. 10 piksellik bir dither, 0.5 piksellik bir dither ile tamamen aynı faz çeşitliliğini sağlar — üstelik sabit desen gürültüsünü ve yürüyen gürültüyü de temizler. Bu yüzden: birkaç piksel dither yapın, rastgele. Alt-piksel dither yapmaya çalışmayın.
BÖLÜM 7
PHD2 Guiding: sıfırdan
Dithering'i pratikte kim yapıyor? Çoğu kurulumda PHD2 adlı ücretsiz bir program. Adı "Push Here Dummy 2" — yani "düğmeye bas yeter" — ve gerçekten de öyle çalışır. İki işi var: uzun pozlar boyunca teleskobu hedefte tutmak, bir de çekim programınız her poz bitiminde "şimdi kaydır" dediğinde dithering yapmak.
Rehberleme döngüsü
Kurulum sırası (ilk kez yapıyorsanız)
- Yeni profil sihirbazı. Rehber kameranızın piksel boyutunu ve rehber teleskobunuzun odak uzaklığını girin. PHD2 bunlardan görüntü ölçeğini ve akıllı min-move varsayılanlarını türetir. Bu adımı atlamayın — yanlış girilen odak uzaklığı, tüm rehberleme davranışını bozar.
- Kalibrasyon. Gök ekvatoruna yakın (DEC 0° ± 20°) ve meridyene yakın bir bölgeye çevirin. PHD2 buradan sensörün RA/DEC eksenlerine göre açısını ve milisaniye başına ne kadar hareket ettiğini ölçer. Yön başına 8–14 adım hedefleyin; 8'in altındaysa Calibration step-size değerini düşürün. Kundak rehber hızı 0.5×–1× yıldız hızı olsun (1× tercih edilir).
- Guiding Assistant çalıştırın. Rehberlemeyi kapatıp 2–5 dakika ölçüm yapar; size seeing kaynaklı yüksek frekanslı hareketi, RA/DEC sürüklenmesini, kutup hizası hatasını ve DEC boşluğunu (backlash) söyler. Önerdiği min-move değerlerini uygulayın.
- Rehber pozu. RA takibi iyi kundaklarda 2–4 sn; periyodik hatası büyük kundaklarda 1–1.5 sn. PHD2 kılavuzu başlangıç noktası olarak 1–3 saniyeyi önerir ve şunu ekler: "Bazı kullanıcılar 1 sn hatta 0.5 sn pozlarla çalışır — bu durumda çoklu yıldız rehberlemesi daha da önemli hale gelir." Kısa pozlar seeing'i kovalama riski taşır.
PHD2 grafiğini okumak
RMS: rehberleme kaliteniz
PHD2 size RA RMS, DEC RMS ve Total RMS değerlerini hem piksel hem yay saniyesi cinsinden verir. Yay saniyesine bakın — piksel değeri ekipmana göre değişir, karşılaştırılamaz.
| Total RMS | Değerlendirme | Not |
|---|---|---|
| 0.5 – 0.8″ | Mükemmel | İyi kundak + iyi seeing |
| 0.8 – 1.2″ | İyi | PHD2 dokümantasyonunun hedef bandı |
| 1.2 – 2.5″ | Sınırda | Uzun odakta yıldızlar şişer |
| > 3.5″ | Kötü | Gözle görülür bozulma |
Nereye kadar iyileştirmeli? Basit bir hedef: rehberleme hatanız, bir pikselin gördüğü alanın yarısı kadar olsun. Her piksel 2 yay saniyesi görüyorsa 1 yay saniyelik hata gayet iyidir. Ama her piksel 0.5 yay saniyesi görüyorsa aynı hata yıldızlarınızı şişirir. Yani "iyi rehberleme" mutlak bir sayı değil, ekipmanınıza göre değişen bir eşik.
İki eksenden birinin ötekinden biraz kötü olması normal. Aralarında iki üç kat fark varsa yıldızlar bir yöne uzamış çıkar, oraya bakmak gerekir. Bir de şunu unutmayın: havayı rehberleyemezsiniz. Yıldızların zaten 3.5 yay saniyesi şiştiği bir gecede 0.4'lük bir rehberleme hatasının peşine düşmek, hiçbir şeyi değiştirmez.
"Rehberleme zaten rastgele hata yapıyor, o hâlde bedava dither alıyorum" diye düşünmek cazip ama yanlış. İki farklı şeyi karıştırmamak gerekiyor:
Pozlar arası kayma: alt-piksel faz çeşitliliği sağlar → faydalı. Ama dithering bunu zaten kasten ve daha iyi sağlıyor; rehberleme hatası buna bir şey eklemiyor.
Poz sırasındaki titreşim: PSF'i genişletir, yıldızları bulanıklaştırır ve uzatır → drizzle'ın kurtarmaya çalıştığı detayı yok eder. Drizzle örneklemeyi onarır, optiği/atmosferi değil. Bulanıklaşmış detay her karede kayıptır, geri gelmez. Üstelik drizzle 2× kusurları da büyütür: uzamış yıldızlar drizzle ile yuvarlaklaşmaz, daha büyük ve daha belirgin uzamış yıldızlar olur.
BÖLÜM 8
PHD2 dither ayarları: her parametre
Nerede? Advanced Settings → Global sekmesi
| Ayar | Varsayılan | Ne yapar |
|---|---|---|
| Random (radyo) | Seçili | Her dither komutunda her eksen için bağımsız rastgele bir miktar üretir. Drizzle için doğru seçim budur. |
| Spiral (radyo) | Kapalı | Sabit boyutlu adımlarla saat yönünde spiral çizer. PHD2 dokümantasyonu bunu "çekim kamerasında belirgin sabit desen gürültüsü varsa ya da kundakta rahatsız edici miktarda DEC boşluğu varsa" önerir. Aynı pozisyona dönmemeyi garanti eder. |
| RA only (kutu) | Kapalı | Sadece RA ekseninde dither yapar. DEC boşluğu sorunu olanlar için kaçış yolu — ama drizzle açısından zayıf (aşağıya bakın). |
| Scale (çarpan) | 1.0 (aralık 0.1–100) | Çekim uygulamasından gelen dither miktarını çarpar. NINA / Ekos / ASIAIR kullanıyorsanız 1.0'da bırakın — miktarı zaten uygulamada giriyorsunuz. |
NINA'da "Dither Pixels = 10" yazıp aynı anda PHD2'de "Scale = 3" bırakmak. Bunlar çarpılır: 30 rehber pikseli dither yaparsınız. Bazı kurulumlarda bu 100+ çekim pikseli demektir ve her dither dakikalarca oturma süresi yaratır. Çekim uygulaması miktarı doğrudan belirtiyorsa, PHD2'nin Scale değeri 1.0 olmalıdır. Scale'i yalnızca SGP/APT gibi "Small/Medium/High" hazır kademeleri kullanan uygulamalarda yükseltin.
Birim tuzağı: hangi pikselin pikseli?
Burada herkesin düştüğü bir tuzak var. Dither miktarını girdiğiniz kutu — programınızda adı ne olursa olsun — rehber kameranızın pikselini kastediyor, çekim kameranızınkini değil. İki kameranın pikselleri farklı boyutta olduğu için, girdiğiniz sayı gökyüzünde bambaşka bir kaymaya karşılık gelebilir.
İki dokümante edilmiş istisna var ve ikisi de kafa karıştırır: NINA'nın "Direct Guider" / "Mount Dither" modu ve APT'nin "Direct Dithering" modu, aynı isimli alanı çekim kamerası pikseli olarak yorumlar. Rehber kamerası olmadan dither yaparken bunu unutmayın.
Hesaplayıcı 3 — Dither miktarı çevirici
Rehber pikselinde girdiğiniz sayının çekim kameranızda kaç piksele karşılık geldiğini bulun. Hedef: 5–15 çekim pikseli (OSC/DSLR için 10–20).
Formül: çekim pikseli = dither miktarı × PHD2 Scale × (rehber ölçeği ÷ çekim ölçeği). OAG kullanıyorsanız iki odak uzaklığını da aynı girin — o zaman oran sadece piksel boyutları oranına iner.
Yaygın forum tavsiyesi "OAG'de rehber pikseli = çekim pikseli, o yüzden yarısını kullan" der. Bu sadece iki kameranın piksel boyutu aynıysa doğrudur. Doğru çarpan piksel boyutları oranıdır: ASI174MM Mini (5.86 µm) rehber + IMX571 (3.76 µm) çekim ile oran 1.56×'dir — yani 5 rehber pikseli sadece 7.8 çekim pikseli eder. Genel gözlem doğru: OAG kullanıcıları rehber teleskobu kullananlardan daha büyük dither sayısına ihtiyaç duyar.
Oturma (settle) parametreleri
Bu üç sayıyı PHD2'nin arayüzünde bulamazsınız — çekim yazılımınız belirler ve komutla PHD2'ye gönderir.
| Parametre | Anlamı | Tipik | Yanlış ayarın bedeli |
|---|---|---|---|
| pixels (PT) | Kabul edilebilir maksimum rehber hatası | 1.0 – 2.5 px | Çok küçükse asla oturmaz; çok büyükse poz erken başlar, yıldızlar çizgilenir |
| time (ET) | Hatanın PT altında kalması gereken süre | 5 – 15 sn | Çok uzunsa her dither zaman aşımına uğrar |
| timeout (TO) | Pes edip devam etme süresi | 40 – 90 sn | Çok kısaysa poz gereksiz erken başlar |
PHD2'nin kendi dokümantasyonundaki referans örnek: {"pixels":1.5, "time":8, "timeout":40}. NINA da tam olarak bu değerlerle gelir (1.5 px / 10 sn / 40 sn).
PHD2 kaynak kodunda, PT ile karşılaştırılan değer anlık hata değil; α = 0.3 ile üstel hareketli ortalamadır ve dither miktarı bu ortalamaya anında eklenir. Yani metrik her rehber karesinde yaklaşık ×0.7 azalır. Ayrıca ET sayacı, PT'nin dışına çıkan her karede sıfırdan başlar. Pratikte dither başına 15–40 saniye ölü zaman bütçeleyin; DEC boşluğu varsa bu rahatlıkla iki katına çıkabilir.
Ne sıklıkta dither?
| Poz süresi | Öneri | Kayıp oran | Gerekçe |
|---|---|---|---|
| 15 – 60 sn | Her 2–5 karede bir | ~13% | Her karede dither, gecenizin üçte birini oturmaya harcar |
| 60 – 120 sn | Her 1–3 karede bir | ~11% | Dengeli |
| 180 – 300 sn | Her karede | ~7% | Overhead ihmal edilebilir |
| 600 sn+ (dar bant) | Her karede, büyük dither | ~3% | Bedava sayılır |
Drizzle'ın umursadığı şey kaydırmanın büyüklüğü değil, kaç farklı konumdan çektiğiniz. 200 kareyi her üç karede bir kaydırarak çekerseniz yaklaşık 66 farklı konumunuz olur; bu iki kat büyütme için fazlasıyla yeterlidir.
Uygulama bazında varsayılanlar
| Uygulama | Dither miktarı | PT | ET | TO | Not |
|---|---|---|---|---|---|
| PHD2 (Scale) | 1.0× | — | — | — | Çarpan; 1.0'da bırakın |
| N.I.N.A. | 5 px | 1.5 | 10 sn | 40 sn | Port 4400; "Dither every # frames" |
| Ekos / KStars | 2 px | 1.0 | 0 sn | 45 sn | PT=1.0 sıkı; zaman aşımı sık görülür |
| SGP | Small → Extreme kademeleri | Kullanıcı belirler | Bağımsız çarpanı yok; PHD2 Scale ile ölçekleyin. Resmi yardım sayfaları çevrimdışı | ||
| APT | Değer 1–5 = 0.5/1/2/3/5 rehber px | Kullanıcı belirler | Geliştirici en az "2" veya "3" öneriyor | ||
| ASIAIR | "Distance" (rehber px) | "Stability" yay saniyesi cinsinden! | Diğerlerinden farklı birim | ||
Çekim yazılımınız PHD2 ile TCP port 4400 üzerinden JSON-RPC ile konuşur (PHD2'de Tools → Enable Server açık olmalı). Gönderilen komut şudur:
"settle":{"pixels":1.5, "time":8, "timeout":40}}, "id":42}
PHD2 geri GuidingDithered, ardışık Settling ve son olarak SettleDone olaylarını yayınlar. Çekim yazılımı SettleDone'ı görene kadar deklanşöre basmaz. Bir şeyler ters gittiğinde bakılacak yer PHD2 log'larıdır (LogViewer aracı).
BÖLÜM 9
Sorun giderme
"Timed out waiting for guider to settle" hatası alıyorum
Sıklık sırasına göre nedenler:
- PT seeing'iniz için fazla sıkı. Normal RMS'iniz 0.8 piksel ise 0.5 pikselde oturamazsınız. Kural: PT ≈ tipik rehber RMS'inizin 2 katı, en az ~1.0 px. PHD2 geliştiricilerinin klasik tavsiyesi 1.5'ten 2.0'a gevşetmektir.
- ET fazla uzun. Sayaç her sapmada sıfırlanır; 15 saniye kesintisiz uyum çok şey istemektir. 8–10 saniye makul, sorun devam ederse 3–5 saniyeye inin.
- Dither fazla büyük. Belgelenmiş bir vakada kullanıcı 12 rehber pikseli dither yapıyor ve ~3 dakikalık oturma süreleri görüyordu; 3 piksele indirince sorun bitti. Hesaplayıcı 3'ü kullanın.
- DEC boşluğu (backlash). Aşağıdaki maddeye bakın.
PHD2 dokümantasyonu açıkça şunu der: "Oturma sırasında ara sıra zaman aşımı olması oldukça yaygındır ve tipik olarak sorun yaratmaz." Gecede bir iki zaman aşımı için panik yapmayın.
DEC boşluğu (backlash) oturma sürelerimi mahvediyor
Dither, tanımı gereği DEC yönünü tersine çevirir — bu yüzden boşluk en çok dither sırasında canınızı yakar. Belirti: kalibrasyonda RA 10 adım alırken DEC 42 adım alıyor.
PHD2'nin resmi çözüm sırası:
- Kundağın kendi backlash telafisini kullanmayın.
- Sonsuz vida / dişli boşluğunu mekanik olarak ayarlayın.
- Kutup hizasını kasten 10 yay dakikasına kadar bozun — böylece DEC hep aynı yönde sürüklenir ve yön değiştirmez. (Evet, resmi tavsiye budur.)
- PHD2'nin kendi backlash telafisi: Guiding Assistant ölçtüğü boşluk 100–3000 ms aralığındaysa önerir. 3 saniyenin üstündeyse "bunun iyi çalışması olası değil" der ve tek yönlü DEC rehberlemesine (North-only / South-only) geçmenizi ister.
- Son çare: Spiral dither moduna geçin — PHD2 bunu özellikle DEC boşluğu için önerir ve RA-only'nin aksine iki eksende de kapsama sağlar.
RA-only dither kullanmalı mıyım?
Şu durumlarda evet: ağır DEC boşluğu, DEC rehberlemesi olmayan kundak, tek yönlü DEC rehberlemesi, alt-azimut kurulum.
Ama drizzle hedefiniz varsa dürüst uyarı: RA-only, alt-piksel faz çeşitliliğini tek eksende sağlar. Dikey eksendeki faz, DEC sürüklenmesine, seeing'e ve rehberleme gürültüsüne kalır — genelde bir miktar vardır ama tasarımla garanti edilmemiştir. Drizzle önceliğinizse Spiral mod, RA-only'den daha iyi bir uzlaşmadır: boşluk sorununu hafifletir ve iki eksende de kapsama verir.
Ayrıca PHD2'nin, kılavuzda geçen ama gözden kaçan iki davranışı var: DEC rehberleme modu "Off" ise, kutu işaretli olmasa bile dither RA-only olur. Ve tek yönlü DEC rehberlemesi kullanıyorsanız, PHD2 dither oturması boyunca DEC'i geçici olarak "Auto"ya alır, sonra eski moda döner ("Eğer dithering PHD2 sunucu arayüzü üzerinden yapılıyorsa, dither'ları gerçekleştirebilmek için tek yönlü DEC rehberlemesi geçici olarak «Auto»ya çevrilir").
Dither yapıyorum ama yürüyen gürültü / sıcak piksel izleri devam ediyor
Dither'iniz muhtemelen fiilen çok küçük. Hesaplayıcı 3 ile çekim kamerasındaki gerçek hareketi hesaplayın. 3 çekim pikselinin altındaysa dither yapmıyorsunuz demektir.
En sık sebep: OAG kullanıcılarının varsayılan 5 pikselde kalması, ya da uzun odaklı rehber teleskobunun oran R'yi 1'in altına düşürmesi.
İkinci sebep: dither aralığı çok seyrek. Etkili eleme için en az ~10 farklı dither pozisyonu gerekir; 30 karelik bir sette her 10 karede bir dither yaparsanız 3 pozisyonunuz olur — yetersiz.
Rehber kameram yok. Dither yapabilir miyim?
Evet, üçü de kundak darbeleriyle çalışır:
- N.I.N.A. "Direct Guider" / "Mount Dither" — ASCOM kundak
PulseGuidedestekliyorsa çalışır. Kaynak kodda: rastgele bir açı seçer, mesafeyi normal dağılımdan (σ = Dither Pixels, ±3σ'da kırpılmış) çeker ve çekim kamerasının piksel ölçeğini kullanır. Ayrıca PHD2'nin aksine mutlak bir hedefe göre çalışır, yani alan yavaşça kaçmaz. - Ekos "Non-Guide Dither" — varsayılan 500 ms darbe.
- APT "Pulse Dithering" — girdiğiniz değer × 100 = maksimum darbe süresi (ms).
Yıldız takipçisi (star tracker) ile çekim yapanlar için bu özellikle değerlidir: rehbersiz kurulumlarda en kötü kusur yürüyen gürültüdür ve kaba bir dither bile onu büyük ölçüde çözer.
PHD2'nin Random modu alanı yavaşça kaçırıyor mu?
Evet — ve dokümantasyon bu konuda yanıltıcı. Kılavuz, rastgeleliğin karenin "daha önce bulunduğu bir konuma" dönmesini engellediğini söyler. Ancak kaynak kodda dither, kilit noktasının göreli hareketidir; yani sınırlandırılmamış bir rastgele yürüyüştür. Eksen başına N dither sonrası sapma ≈ miktar × √(N/3). 5 piksel × 100 dither ≈ 29 rehber pikseli kayma.
Pratikte bu bir felaket değil: PHD2, kilit noktası sensör kenarına yaklaşırsa dither'i içeri doğru yansıtır, bu da yürüyüşü sınırlar. Yine de son yığınınızda kenarlardan biraz kırpma payı bırakın. Kesin çözüm isterseniz: Spiral mod (sürüklenme yok) veya Ekos (özgün hedef konumunu takip edip geri çeker).
Dokümantasyonun söylemediği: dither gerçekte ne kadar hareket ediyor?
PHD2 kılavuzu, miktarı "sıfır ile bu limit arasındaki rastgele değerlerin üst sınırı" olarak tarif eder. Kaynak koddaki gerçek davranış farklı: her eksen için [−miktar, +miktar] aralığında düzgün dağılımlı bağımsız bir değer üretilir.
Sonuç: "5 piksel dither" eksen başına ortalama 2.5 piksel gerçek hareket demektir, 5 değil. Hedeflediğiniz hareketi tutturmak için bunu hesaba katın — ya da basitçe hesaplayıcının verdiği sayıya bakıp sonucu gözlemle doğrulayın.
BÖLÜM 10
Yazılımlar: kim gerçekten drizzle yapıyor?
Bir yazılımın menüsünde "Drizzle" yazması, Fruchter & Hook algoritmasını çalıştırdığı anlamına gelmiyor. Bazıları gerçek drizzle, bazıları "önce büyüt sonra yığınla" yapıyor. Farkı bilmek önemli.
PixInsight — DrizzleIntegration
Amatör dünyanın en yetenekli ama en az belgelenmiş drizzle uygulaması. PixInsight'ın resmi referans dokümantasyonunda DrizzleIntegration sayfası yoktur — dolaşımdaki tüm "varsayılan değerler" üçüncü taraf kaynaklardan gelir. Bu, konuyla ilgili folklorun neden bu kadar bol olduğunu kısmen açıklıyor.
Üç aşamalı iş akışı
- StarAlignment (veya WBPP kaydı), "Generate drizzle data" açık → her kare için bir
.xdrzdosyası yazılır. İçinde geometrik dönüşüm, yüzey spline'ları ve CFA deseni bilgisi vardır. - ImageIntegration normal şekilde çalıştırılır →
.xdrzdosyalarının içine kare ağırlıkları, eleme maskeleri ve normalizasyon verisi geri yazılır. Bu adım zorunludur; atlarsanız DrizzleIntegration ağırlıklandırma ve eleme yapamaz. - DrizzleIntegration görüntüleri değil,
.xdrzdosyalarını alır (isteğe bağlı.xnmlyerel normalizasyon dosyalarıyla birlikte) ve master'ı üretir.
| Parametre | Bildirilen varsayılan | Not |
|---|---|---|
| Scale | 2 | Doğrusal büyütme. 2× = 4 kat piksel, ~4 kat dosya |
| Drop shrink | 0.9 | PixInsight'ın pixfrac adı. Optimum değil — R ≈ 2.21 verir |
| Kernel function | Square | Square / Circular / Gaussian + "Variable shape" varyantları |
| Enable CFA drizzle | Kapalı | WBPP'de OSC verisi için otomatik açılır |
| Enable rejection | Kaynaklar çelişiyor | Açın. ImageIntegration'ın yazdığı eleme maskelerini kullanır |
| Enable image weighting | Kaynaklar çelişiyor | Açın. Kare kalitesi ağırlıklarını uygular |
| Truncate on out-of-range | Kaynaklar çelişiyor | Kapalı olduğundan emin olun — açıksa doymuş yıldız çekirdekleri siyah çıkabilir |
Uyarı: Yukarıdaki değerler üretici dokümantasyonundan değil, üçüncü taraf rehberlerden derlenmiştir ve bazı satırlarda kaynaklar birbiriyle çelişmektedir. Kesin bilgi için DrizzleIntegration aracını PixInsight'ta açıp arayüzdeki değerleri kendiniz okuyun.
2× / 0.9 kombinasyonu Fruchter & Hook'un kendi formülüne göre R ≈ 2.21 verir. Aynı ölçekte pixfrac 0.5 kullanırsanız R = 1.50, makalede tipik örnek olarak verilen 0.6 ile R = 1.66. Bu, varsayılanın "yanlış" olduğu anlamına gelmez — büyük damla, az kareyle delik riskini düşürür ve muhtemelen güvenli tarafta kalmak için seçilmiş. Ama yeterli kareniz varsa drop shrink'i 0.6'ya doğru indirmeyi deneyin ve çıktıda delik olup olmadığına bakın; daha keskin ve daha az korele bir sonuç alırsınız.
Kernel seçimi — folklorla ölçüm çelişiyor
Forumlarda "Circular daha keskin yıldız verir" denir. 16 alt kareli ölçümlü bir testte (2× drizzle, 0.9 drop) sonuç şuydu:
| Kernel | Ölçülen gürültü | Yorum |
|---|---|---|
| Drizzle yok | 2.590e-4 | Referans |
| Square | 1.511e-4 | En iyi — hem en hızlı hem en düşük gürültü |
| Circular | 2.015e-4 | Daha yavaş ve daha gürültülü |
| Gaussian | 2.580e-4 | Drizzle yapmamakla neredeyse aynı; çok daha yavaş |
Bu tek bir test — ama Square'in varsayılan olmasının bir sebebi var. Gaussian, akı korumalı değildir; fotometri yapacaksanız Square kullanın. Az kareyle Gaussian denemeyin, iyi çalışması için çok kare ister.
Siril — amatör dünyanın en iyi belgelenmiş drizzle'ı
Siril 1.2 dokümantasyonu bunu kendisi itiraf ediyordu: "Bu yöntemin doğru adı süper çözünürlüklü yığınlama olmalıdır, ama anlaşılması daha kolay olsun diye ona Simplified Drizzle x2 adını verdik." Gerçek Fruchter & Hook algoritması Siril 1.4 ile geldi (beta Nisan 2025, kararlı sürüm 5 Aralık 2025). Siril'in FAQ sayfası hâlâ eski açıklamayı taşıyor — dokümantasyon gecikmesine güzel bir örnek.
Siril'de drizzle, kayıt algoritmasının değil, enterpolasyon adımının yerine geçer. Global Star Alignment gibi kayıt yöntemleriniz aynı kalır; sadece pikselleri yeni ızgaraya taşıma biçimi değişir.
Kernel'ler — Siril'in kendi açıklamalarıyla
| Kernel | Karakter | Ne zaman |
|---|---|---|
| Square | "Yapı gereği matematiksel olarak akı korumalı" — her giriş pikselinin akısı tam örtüşme oranında dağıtılır | Varsayılan seçim. Fotometri yapacaksanız zorunlu |
| Point | "Çok küçük piksel kesirli square kernel'in limiti". En düşük korele gürültü | Çok fazla kare varsa; aksi halde delik bırakmaya yatkın |
| Turbo | Square'in basitleştirilmiş, dönmeyi ihmal eden hali. Çok daha hızlı, yaklaşık | Hızlı deneme turları |
| Gaussian | Damla Gauss olarak modellenir (FWHM = pixfrac). Akı korumalı değil | "Yıldız şekillerinin korunması önemliyse". Kare bloklu görünümü yumuşatır |
| Lanczos2 / 3 | Bir WCS'ten diğerine aynı ölçekte yeniden örnekleme için | "Yalnızca scale = pixfrac = 1.0 ile kullanılmalıdır" |
Siril'in kural ve uyarıları (hepsi doküman alıntısı)
- "Piksel kesri kabaca drizzle ölçeğinin tersi olmalıdır" → 2× için pixfrac ≈ 0.5. (Bu, damlanın tam bir çıktı pikseli boyutunda olduğu denge noktasıdır — Bölüm 5'e bakın.)
- "Drizzle'ın sağladığı çözünürlük kazancı gürültü pahasına gelir."
- Ara kareler tuhaf görünür — panik yapmayın. "Drizzle'lanmış dizideki tek tek kareler tuhaf görünebilir ve görünecektir: referans kare çoğu zaman diğerlerinden farklı görünür, özellikle CFA verisi drizzle'lanırken ve diğer kareler Moiré desenleri gösterebilir... Bunların hepsi yığınlama aşamasında çözülecektir."
- Boş pikseller. "Hiç giriş almayan çıktı pikselleri siyahtır" ve dönüşümün geometrisine bağlı desenler oluşturdukları için Moiré gibi görünürler. Siril yığınlamada tam sıfır olan pikselleri yok sayar, yani yeterli kareyle sorun kendiliğinden çözülür.
- Eleme yöntemi. "Drizzle'lanmış CFA görüntülerde Kırmızı ve Mavi kanallarda bazı yöntemlerle tatmin edici eleme sağlamak zor olabilir. Bu durumlarda MAD Clipping en etkili yöntem gibi görünmektedir."
- Maliyet. "Bellek ve disk alanı ihtiyacı, drizzle ölçek faktörünün karesiyle çarpılır."
DeepSkyStacker — "drizzle" ama tam olarak değil
DSS'in kendi teknik sayfasındaki tarif şu: "her görüntü yığınlanmadan hemen önce, iki veya üç kat büyütülerek süper-örneklenir... sonra daha ince bir piksel ızgarasına yansıtılır."
Bu önce büyüt-sonra yığınladır; değişken pikselli doğrusal yeniden yapılandırma değil. DSS'te pixfrac / drop shrink parametresi yoktur, kernel seçimi yoktur, ağırlık haritası mekanizması yoktur. Yani işlevsel olarak Siril'in 1.2'de dürüstçe "süper çözünürlüklü yığınlama" dediği şeydir.
Bu bir suçlama değil — DSS zaten pixfrac iddiasında bulunmuyor. Ama "DSS'te drizzle açtım" ile "PixInsight'ta drizzle yaptım" aynı şey değildir; bunu bilerek karşılaştırma yapın.
DSS, gereksinim olarak sadece "birbirine tam hizalı olmayan çok sayıda görüntü; birkaç piksellik sürüklenme yeterlidir" diyor — yani kasıtlı dithering'i şart koşmuyor, tesadüfi sürüklenmeye güveniyor. Diğer tüm paketlerin rehberliğinden zayıf bir yaklaşım. Siz yine de dither yapın.
DSS'te "Bayer Drizzle" bambaşka bir şey
Kafa karıştıran nokta: DSS'te Bayer Drizzle bir yığınlama seçeneği değil, bir debayer (renk açma) seçeneğidir. RAW/FITS enterpolasyon menüsünde Bilinear, AHD ve Super Pixel'in yanında durur. DSS'in FAQ'si bunu "enterpolasyon yapmayan modlar (Bayer Drizzle ve Super Pixel)" diye gruplar.
Ve DSS'in kendi açık uyarısı: "Drizzle yönteminin iki çeşidini kullansalar da, Drizzle ve Bayer Drizzle seçeneklerini birlikte kullanmak önerilmez."
Maliyet: DSS de karesel maliyeti belirtiyor — 3000×2000 bir görüntüde 2× drizzle "4 kat bellek ve disk alanı", 3× ise "9 kat". DSS'in önerdiği hafifletme: Custom Rectangle ile sadece ilgilendiğiniz bölgeyi işlemek.
AstroPixelProcessor — en dürüst uyarılar
APP'nin Integrate sekmesindeki parametreler: Integration mode (normal / Bayer Drizzle / X-Trans drizzle), Integration scale, Drizzle drop size, Drizzle kernel (örn. tophat).
Geliştirici Mabula Haverkamp'ın terimler arası çeviri notu: "0.5 damla boyutu ve 2 ölçek, 2× drizzle ile aynı şeydir." Yani APP'nin drop size'ı diğerlerinin pixfrac'i gibi giriş-pikseli biriminde.
APP'nin üç şartı (mono veri için)
- Yetersiz örneklenmiş veri — "görüntü ölçeğiniz atmosferik seeing'den büyükse". APP tipik örnek olarak ~200 mm altı odak uzunluklarını gösteriyor.
- İyi dither'lanmış veri — "bu dither kaymalarının yalnızca alt-piksel boyutunda olması yeterlidir". (Dikkat: bu, kaymanın alt-piksel olması gerektiği anlamına gelmiyor; alt-piksel kadar küçük bir kaymanın bile yettiği anlamına geliyor.)
- Çok veri — "gürültü artışını dengelemek için çok veri gerekir", çünkü "Drizzle BÜYÜK bir gürültü enjektörüdür!"
APP, gürültü korelasyonunu düz Türkçeyle (İngilizceyle) belgeleyen tek amatör pakettir: "komşu piksellerdeki gürültü korelasyonlu olacaktır" — yani ölçülen gürültü gerçeği eksik gösterir. Bu yazının Bölüm 5'inde anlattığımız R faktörünün ta kendisi.
Bayer Drizzle reçetesi (resmi FAQ)
- Integration mode = Bayer Drizzle
- Integration scale = 1.0
- Drizzle drops = 2.0
- Drizzle kernel = tophat
Kural: "Renkli/OSC veride Bayer drizzle kullanırken damla boyutunu mono ayarlarına göre iki katına çıkarın" — çünkü her renk kanalında fotositlerin sadece %25–50'si katkı yapar.
Ve geliştiricinin dürüst beklenti yönetimi: bu ayarlarla sonuç "AAD debayer ile normal entegrasyona (drizzle'sız) benzer olmalıdır". Bayer drizzle'ın vaadi çözünürlük değil, gürültü dokusu.
ASTAP — normal drizzle kaldırıldı
Bu, konu hakkındaki en az bilinen ve en anlamlı gelişmelerden biri. ASTAP geliştiricisi Han Kleijn, resmi forumda şunları yazdı:
"Drizzle seçeneği kaldırıldı çünkü çok nadiren kullanılıyordu (yalnızca yetersiz örneklenmiş görüntüler için)."
"Normal drizzle'ı geri eklemeyeceğim. Bugünlerde piksellerinin çok büyük olduğu ve drizzle gerektiren (yani yetersiz örneklenmiş) amatörler olduğuna dair bir belirti görmüyorum. Çoğu, küçük piksel boyutları ve göreli kötü seeing yüzünden aşırı örneklenmiş görüntülere sahip."
Gerekçesi sağlam: drizzle, atmosferi olmayan bir uzay teleskobu için tasarlandı. 2020'lerin amatör kurulumları, modern CMOS sensörlerin küçük pikselleri yüzünden ezici çoğunlukla aşırı örneklenmiş durumda.
ASTAP'ta Bayer/CFA drizzle yığınlama yöntemi olarak duruyor — geliştiricinin uyarısıyla: "İyi bir sonuç için çok sayıda görüntüye ihtiyacınız olacak, aksi halde pürüzsüz renkler elde edemezsiniz." Klasik drizzle isteyenleri de açıkça yönlendiriyor: "Ama gereksinimlerinize daha uygunsa DSS kullanın."
Bu, "her zaman drizzle aç" tavsiyesine karşı elimizdeki en güçlü tek argüman: bir yazılım yazarı, özelliği örnekleme gerekçesiyle tamamen kaldırdı.
BÖLÜM 11
Bayer / CFA drizzle: renkli kameralar için
Renkli (OSC) bir kameranız ya da DSLR'ınız varsa, bu bölüm muhtemelen sizin için klasik drizzle'dan daha değerli.
Problem: debayer bir tahmin işlemidir
Renkli kamera sensöründe her fotositin önünde tek bir renk filtresi vardır — kırmızı, yeşil veya mavi. Standart RGGB düzeninde piksellerin %25'i kırmızı, %50'si yeşil, %25'i mavidir. Yani her piksel için üç renk değerinden ikisi hiç ölçülmemiştir; debayer algoritması onları komşulardan tahmin eder.
Bu tahmin fena değildir ama bedava değildir: kenarlarda sahte renkler, ince yapılarda "fermuar" ve labirent desenleri, ve arka planda debayer'ın kendi imzasını taşıyan yapılı gürültü bırakır.
Nasıl yapılır
| Yazılım | Ayar adı | Önerilen değerler |
|---|---|---|
| PixInsight | Enable CFA drizzle | Scale 1, Drop shrink 1.00, kernel Square. WBPP'de ayrı kutu yok: Calibration'da CFA images, Post-Calibration'da Drizzle işaretleyin — CFA drizzle otomatik seçilir |
| Siril 1.4+ | Bayer Drizzle | Kalibrasyonda "Debayer before saving" işaretini kaldırın. Sonra scale = pixfrac = 1.0. Yığınlamada MAD Clipping elemesi |
| APP | Integration mode: Bayer Drizzle | scale 1.0, drops 2.0, kernel tophat |
| ASTAP | Stack method | Tek kalan drizzle türü. Çok kare gerekir |
| DSS | RAW/FITS debayer seçeneği | Normal Drizzle ile birlikte kullanmayın |
Bir kere debayer yaptıysanız, tahmin edilmiş değerler ölçülmüş olanlardan ayırt edilemez hale gelir — orijinal "piksel başına tek renk" yapısı yok olmuştur. Bu yüzden iş akışının en başında karar vermeniz gerekir: kalibre edin, ama debayer etmeyin. CFA deseni drizzle girdisine kadar korunmalıdır.
Beklentiyi doğru kurmak
Siril'in dokümantasyonu, amatör pazarlamasının aksine, alışılmadık derecede dürüst:
"Kullanıcılar, sonuçları debayer edilmiş yığınlanmış görüntülerle karşılaştırdıklarında sonuçları hayal kırıklığı yaratıcı bulabilir. Genellikle kazanç vardır, ancak marjinal olabilir (örneğin FWHM'de birkaç yüzdelik iyileşme)."
"Debayer işlemi kaybolan çözünürlüğün bir kısmını zaten geri kazandırıyor." Kazanımlar "yetersiz örneklenmiş mono veriyi drizzle'lamaktan elde edilecek çözünürlük kazanımları kadar etkileyici değil."
Öyleyse CFA drizzle'ın gerçek getirisi ne? Gürültü karakteri ve artefakt temizliği. Siril: drizzle'lı sonuçta "gürültü çok daha temiz" ve "tipik bir debayer edilmiş CFA yığınının arka planında görülen yapıdan yoksun". PixInsight tarafındaki iddialar: kalıcı yeşil renk sapmasının ortadan kalkması ve büyük ölçekli renk gürültüsünün azalması.
Neden CFA'da scale = 1? Çünkü kırmızı ve mavi kanallar sensörün sadece %25'ini kaplar. Ölçeği 2×'e çıkarmak, zaten seyrek olan bu kanallarda kapsama açığını dörde katlar. Siril: "scale > 1.0 ile üst örnekleme, seyrek renkli piksel dağılımı nedeniyle önemli ölçüde daha fazla kare gerektirir." Tüm paketler bu yüzden CFA için 1× üzerinde birleşiyor.
BÖLÜM 12
Gezegen görüntülemede drizzle
AutoStakkert!'te de bir drizzle seçeneği var ve tamamen farklı bir dünyada çalışıyor.
| Derin gökyüzü drizzle | Gezegen drizzle | |
|---|---|---|
| Kare sayısı | 20 – birkaç yüz | 1.000 – 10.000+ (lucky imaging) |
| Alt-piksel kayma | Kasten üretilmeli (dithering) | Bedava — seeing titreşimi ve takip hatası her karede rastgele kayma sağlar |
| Yetersiz örnekleme sebebi | Kısa odak / büyük piksel | Yetersiz efektif odak (f/oran, piksel µm'sinin ~3–5 katının altında) |
| Gürültü bedeli | Ağır — foton kıtlığı | Hafif — devasa kare sayısı bastırır |
| Hizalama | Yıldız hizalama + distorsiyon modeli | Çok noktalı hizalama (AP kutuları), yüzey detayları üzerinden |
| pixfrac kontrolü | Kullanıcıya açık | AutoStakkert!'te yok |
| Eleme | Sigma clipping | Kalite sıralaması (en iyi %N kare) |
AutoStakkert!'in kendi sitesi bunu "gelişmiş bir teknik olan drizzling — resmi adıyla Variable Pixel Linear Reconstruction" diye tanıtıyor ama arkasından çok net bir uyarı ekliyor:
"Çoğu gezegen kaydı için drizzle'lamaktan kazanılacak çok az şey var." Fayda sağlayabileceği yerler olarak "düşük odak uzunluklu kayıtlar" ve "düşük odak uzunluklarında kısa pozlu derin gökyüzü hedefleri" gösteriliyor.
Gerekçe: "Görüntüler yetersiz örneklenmemişse — ki yüksek çözünürlüklü astrofotoğraf görüntülerinin çoğunda durum budur — ilk kare, diğer karelerin herhangi biriyle aynı bilgiyi içerecektir."
Gezegen görüntülemede pratik referans noktası: piksel başına 0.1 – 0.25 yay saniyesi aralığı ideal kabul edilir. Bu aralığın üstündeyseniz (yani daha kaba örnekliyorsanız) drizzle denemeye değer.
1.5× / 3× faktörleri: Yaygın açıklama, AutoStakkert!'te aslında tek bir 3× drizzle olduğu ve 1.5×'in bunun 2× küçültülmüş hali olduğu yönünde. Bu forum kaynaklı bir bilgi; üretici dokümantasyonunda yer almıyor.
OSC verisinde 3× drizzle: Kullanıcılar RGB ızgara (gridding) artefaktları bildiriyor — "piksellerin komşularından çok, 3 piksel ötedeki piksellerle daha ilişkili olması" şeklinde tarif ediliyor. Geliştirici algoritmanın iç işleyişini kamuya açıklamadı. AS!4 4.0.13'te "RGB kayıtlarda drizzle kullanırken çökmeye neden olan hata düzeltildi" notu, bu yolun tarihsel olarak kırılgan olduğunu düşündürüyor. OSC ile 3× drizzle kullanacaksanız sonucu dikkatle inceleyin.
BÖLÜM 13
Karar ağacı: drizzle yapmalı mıyım?
Kaç kare gerekir? Rakamlar çelişiyor — nedeni şu
Bu konuda gerçek bir anlaşmazlık var: PixInsight tarafındaki kaynaklar 15–30 derken, eski forum konsensüsü 100+ diyor; APP geliştiricisi ise sayı vermeyi reddediyor ve "dither kalitesi kare sayısından önemli" diyor.
Fiziksel olarak savunulabilir çerçeve şu: gereklilik "N kare" değil, çıktı ızgarasını doldurmaya yetecek kadar farklı alt-piksel konumu. Ölçek S için her çıktı pikselinin kapsanması gerekir, yani mono veride kabaca S² × birkaç iyi dağılmış pozisyon; CFA sensörün seyrek R/B düzlemleri için bunun 4 katı.
| Senaryo | Önerilen minimum | Gerekçe |
|---|---|---|
| Mono, 2× drizzle | 20 – 30 | 4 çıktı hücresi/giriş pikseli × birkaç kat kapsama |
| Mono, 3× drizzle | 50+ | 9 çıktı hücresi/giriş pikseli |
| CFA drizzle, 1× ölçek | 20 – 40 | R ve B düzlemleri fotositlerin sadece %25'i |
| CFA drizzle, 2× ölçek | Denemeyin | 4× seyreklik × 4× hücre = pratikte ulaşılamaz |
BÖLÜM 14
Mitler ve gerçekler
Bu tablodaki her satır, forumlarda yaygın olan bir iddiayı resmi dokümantasyon veya kaynak kodla karşılaştırıyor.
| Yaygın iddia | Gerçek |
|---|---|
| "Drizzle için dither alt-piksel olmalı" | Yanlış Amatör kurulumda gereken şey kaymanın kesirli kısmının rastgele olması. 10 pikselik dither bunu otomatik sağlar ve ayrıca sabit desen/yürüyen gürültüyü de temizler. Birkaç piksel dither yapın. |
| "PHD2, 0 ile maksimum arasında rastgele kaydırır" (PHD2 kılavuzu) | Eksik Kaynak kodda dağılım eksen başına [−maks, +maks] aralığında düzgün. Ortalama gerçek hareket, nominal değerin yaklaşık yarısı. |
| "PHD2 asla önceki bir konuma dönmez" (PHD2 kılavuzu) | Eksik Random modu sınırlandırılmamış bir rastgele yürüyüş; dönebilir ve zamanla sürüklenir. Sadece Spiral modu gerçekten kaçınır. |
| "Dither ne kadar büyükse o kadar iyi" | Yanlış Oturma süresini ve alan kaymasını artırır, yığın alanını daraltır. 12 rehber pikselinin ~3 dakikalık oturma sürelerine yol açtığı belgelenmiş vaka var. |
| "OAG'de rehber pikseli = çekim pikseli" | Yanlış Sadece piksel boyutları aynıysa. Doğru çarpan piksel boyutları oranıdır (5.86/3.76 = 1.56×). |
| "'Dither pixels' her zaman rehber kamera pikselidir" | Çoğunlukla PHD2/NINA-PHD2/SGP/APT-PHD2/ASIAIR için doğru. NINA Direct Guider ve APT Direct Dithering için yanlış — onlar çekim kamerası pikseli kullanır. |
| "Kötü rehberleme rastgelelik katar, drizzle'a yarar" | Yanlış Poz içindeki titreşim PSF'i genişletir; drizzle bu kusuru büyütür. Dithering ve iyi rehberleme birbirinin yerine geçmez, birbirini tamamlar. |
| "Drop shrink 0.9 varsayılan, demek ki doğru" | Muhafazakâr 2× ölçekte R ≈ 2.21 — denge noktasının (0.5, R = 1.50) ve makalenin tipik örneğinin (0.6, R = 1.66) epey üstünde. Az kareyle güvenli, çok kareyle gereksiz yumuşak. |
| "pixfrac ne kadar küçükse gürültü o kadar az" | Yarı doğru Gürültü korelasyonu (R) gerçekten azalır. Ama her çıktı pikseline daha az katkı düştüğü için piksel başına gürültü artar ve delik riski hızla yükselir. R tek başına karar vermez. |
| "Circular/Gaussian kernel daha keskin, onu kullan" | Tartışmalı Ölçümlü bir testte Square hem en hızlı hem en düşük gürültülü çıktı; Gaussian "drizzle yapmamakla neredeyse aynı". Gaussian ayrıca akı korumalı değil. |
| "DSS'te drizzle = PixInsight'ta drizzle" | Yanlış DSS "süper-örnekle sonra yığınla" yapıyor; pixfrac yok, kernel yok, ağırlık haritası yok. |
| "Siril yıllardır drizzle yapıyor" | Yanlış Siril ≤ 1.2'de olan şey açıkça "Simplified Drizzle x2"ydi ve dokümantasyon bunun aslında süper çözünürlüklü yığınlama olduğunu söylüyordu. Gerçek drizzle 1.4 ile geldi (Aralık 2025). |
| "ASTAP'ta drizzle var" | Artık yok Normal drizzle kaldırıldı; geliştirici geri getirmeyeceğini açıkladı. Sadece Bayer/CFA drizzle kaldı. |
| "CFA drizzle çözünürlük kazandırır" | Abartılı Siril: "kazanç marjinal olabilir (FWHM'de birkaç yüzdelik)". Gerçek getiri gürültü dokusu ve artefakt temizliği. |
| "SNR betiği drizzle'lı görüntünün daha iyi olduğunu söylüyor" | Geçersiz ölçüm Korelasyonlu gürültü, piksel-piksel gürültü tahmincilerini R kat iyimser gösterir. |
| "Dither yapmak için rehber kamera şart" | Yanlış NINA Mount Dither, Ekos Non-Guide Dither (500 ms) ve APT Pulse Dithering sadece kundak darbeleriyle çalışır. |
| "PHD2 dokümantasyonu drizzle için dither öneriyor" | Hayır PHD2 kılavuzu drizzle'dan hiç bahsetmez; gerekçe olarak yalnızca sabit desen gürültüsü ve sıcak pikselleri sayar. Drizzle bağlantısı drizzle literatüründen gelir. |
| "Ekos varsayılan olarak 3 piksele kadar dither yapar" (KStars el kitabı) | Eksik Kaynak kodda varsayılan DitherPixels = 2. |
BÖLÜM 15
Tek sayfalık özet
Çekim gecesi kontrol listesi
- PHD2 → Tools → Enable Server açık (port 4400)
- PHD2 → Advanced → Global → Dither: Random, Scale = 1.0, RA only kapalı (DEC boşluğu sorunu yoksa)
- Dither miktarı: Hesaplayıcı 3 ile 5–15 çekim pikseli hedefleyin (OSC/DSLR için 10–20)
- Settle: PT ≈ tipik RMS × 2 (min 1.0 px) · ET 8–10 sn · TO 40–60 sn
- Dither sıklığı: 60 sn altı pozlarda her 2–5 karede bir; 180 sn üstü pozlarda her karede
- Hedef: en az 20 farklı dither pozisyonu
- Guiding Assistant'ı bir kez çalıştırın, önerdiği min-move ve backlash telafisini uygulayın
İşlem masası kontrol listesi
- OSC kamerada: kalibre edin ama debayer etmeyin (Siril'de "Debayer before saving" kapalı)
- Kayıtlı karelerde medyan FWHM'yi ölçün. Karar bu sayıya bağlı
- PixInsight'ta: StarAlignment "Generate drizzle data" → ImageIntegration mutlaka çalıştırın → DrizzleIntegration
- PixInsight'ta "Truncate on out-of-range" kapatın (siyah yıldız çekirdeği riski)
- Kernel: Square ile başlayın
- Çıktıyı %100 zoom'da inceleyin: delik ve Moiré arıyorsunuz
- Drizzle'lı ve drizzle'sız yığını SNR betiğiyle karşılaştırmayın — geçersiz
Başlangıç ayarları
| Senaryo | Ölçek | pixfrac | Kernel | R |
|---|---|---|---|---|
| Mono, yetersiz örneklenmiş (FWHM < 2 px) | 2× | 0.5 | Square | 1.50 |
| Mono, az kare (< 20) | 2× | 0.8 – 1.0 | Square | 2.0 – 2.4 |
| OSC / DSLR — CFA drizzle | 1× | 1.0 | Square / tophat | 1.50 |
| Mono, sadece enterpolasyon artefaktından kaçınmak | 1× | 1.0 | Square | 1.50 |
| Çok kısa odak + çok kare (100+) | 3× | 0.33 | Square | 1.49 |
Drizzle, örnekleme problemini çözer — optiği, atmosferi veya rehberlemeyi değil. Verinizde çözülecek bir örnekleme problemi yoksa drizzle size hiçbir şey vermez; varsa ve dithering yaptıysanız, geri kazanacağınız detay gerçektir.
Kaynaklar
Algoritmanın kaynağı
- Fruchter & Hook — Drizzle: A Method for the Linear Reconstruction of Undersampled Images, PASP 114:144–152 (2002). pixfrac tanımı, akı denklemleri ve R gürültü korelasyon formülleri buradan.
- Fruchter (2011) — A New Method for Band-limited Imaging with Undersampled Detectors
- STScI — Processing Dithered Data · HST DrizzlePac — algoritmanın tarifi
- spacetelescope/drizzle — resmi Python uygulaması dokümantasyonu
- Wikipedia — Drizzle (image processing)
PHD2 ve dithering
- PHD2 Kullanım Kılavuzu · Advanced Settings · Sorun giderme
- PHD2 Best Practices (Waddington & Galasso, 2019) — PDF
- PHD2 Rehberleme Log'larını Analiz Etmek — PDF
- PHD2 Event Server API (port 4400) · Kaynak kod: myframe.cpp, phdcontrol.cpp, guide_algorithm.cpp
- N.I.N.A. — Dithering · Guider ayarları
- KStars/Ekos — Guide modülü · APT — Dithering and Guiding
- Sky & Telescope (Lodriguss) — Why and How to Dither · Dither miktarı hesaplama
Yazılım dokümantasyonu
- Siril — Drizzle (en iyi belgelenmiş amatör uygulama) · Siril 1.4.0 sürüm notu · Siril 1.2 — "Simplified Drizzle x2" itirafı
- APP — Mono kameralar için drizzle · APP — Bayer Drizzle iş akışı
- DeepSkyStacker — Teknik açıklamalar · DSS FAQ
- ASTAP forum — geliştiricinin drizzle'ı kaldırma açıklaması · ASTAP ana sayfa
- PixInsight DrizzleIntegration rehberi (üçüncü taraf) · CFA drizzle · Chaotic Nebula rehberi
- Kernel fonksiyonu gürültü karşılaştırması (ölçümlü test)
- AutoStakkert! — Enhance / drizzle
Ne zaman drizzle yapmalı — pratik tartışmalar
- Cloudy Nights — To Drizzle or Not to Drizzle · Let's talk about drizzling · Aşırı örneklenmiş veride DrizzleIntegration
- Astroshop — Drizzle ne zaman çözünürlük kazandırır
- Seeing ve görüntü ölçeği (Bölüm 1) · Drizzle Integration (Bölüm 2)
- RC Astro — Drizzle + dekonvolüsyon
Bu yazıdaki tüm sayısal değerler yukarıdaki kaynaklardan doğrulanmıştır. R gürültü korelasyon değerleri Fruchter & Hook'un denklem 9 ve 10'undan hesaplanmıştır. PHD2'nin bazı davranışları (dither dağılımının işaretli olması, α = 0.3 üstel ortalama, min-move formülü, rastgele yürüyüşün sürüklenme davranışı) resmi dokümantasyonda yer almaz; bunlar kaynak kod davranışı olarak belirtilmiştir. PixInsight'ın DrizzleIntegration varsayılanları üretici dokümantasyonunda bulunmadığı için üçüncü taraf kaynaklıdır.