Skriva eget stackningsprogram

[megmar]

Har länge funderat på att skriva en egen bildstackare. Inte för att DSS eller andra program är dåliga, utan mest för att det känns som en kul utmaning och sen finns det alltid möjligheter att modda UI mm för ens egna behov.
Började koda idag och startade med en slags hybrid. Align sköter jag fortfarande via DSS (+export till CSV fil), men själva stackningen sker i eget C# program. Än så länge bara en super simpel monokrom medelvärdesstackning. Något som underlättade var när jag läste att Nebulosity använder pixel align istf sub pixel align.

Craig Stark skriver så här på sin blog (http://www.stark-labs.com/help/blog/fil ... arison.php" onclick="window.open(this.href);return false;):

The big difference between "translation" and "translation + rotation (+ scaling)" is that when doing a translation-only alignment, Nebulosity does not resample the image. It does "whole pixel" registration. This sounds worse than "sub-pixel" registration. Isn't it better to shift by small fractions of a pixel? Well, it would be, except for the fact that when you do so, you need to know what the image looks like shifted a fraction of a pixel. That means, you must interpolate the image and interpolation does cause a loss of sharpness. So, you're faced with a trade-off. Keep the image exactly as-is and shift it by whole pixels or resample it and shift it by fractional pixels.

Dels är det såklart simplare att implementera detta, men det är sjukt mycket snabbare också! Kunde stacka 213 bilder (visserligen små) på 8,4 sekunder

Här är en bild jämförelse, min stackare till vänster och DSS till höger. Båda är körda utan darks eftersom jag inte hunnit lägga in dark subtraktion ännu. Tycker man ser tydligt att det blir grynigare med "whole" pixel aligning. Craig menar ju att det är en trade off och att den suddigare interpolationen som blir i tex DSS inte nödvändigtvis är bättre. Svårt att säga, jag tycker nog DSS ser bättre ut

Har en liten roadmap för sommaren:

• Automatic frame aligning
• FWHM analysis
• Dark subtraction
• Background normalization
• Median stacking
• Average stacking with rejection
• Subpixel stacking
• Derotation
• Support RGB images

Edit: La till lite i listan.

[AstroFriend]

Hej,
Att bara aligna i heltals pixel fungerar bara i de enklaste fallen.

DSS är inte speciellt bra på att aligna eller kalibrera bilderna, specielt flats blir dåligt. Dock är ju DSS enkelt att använda, dessutom gratis.

Jag har i AIJ tagit fram makron för att kalibrera bilderna utan darks eller bias, flats behövs dock fortfarande. Dithering behöver i regel göras när man tar bilderna, men det är det värt med alla fördelar man får. Bilderna har jag i ett tidigare steg demosaicat, hanterar det som separata rggb bilder hela vägen.

Stegen därefter som aligning och stackning använder jag färdiga funktioner till. Även rggb alignas relativt varandra.

Blir mycket bättre än något annat av de gratisprogram som jag testat.

Du kan läsa här hur jag gjort.

http://www.astrofriend.eu/astronomy/tut ... ction.html" onclick="window.open(this.href);return false;

Bäst fungerar det idag med Canon dslr kameror.

Du kan också utveckla egna plugin i AIJ och kan använda kärnan där det finns grunderna så du inte behöver göra de delarna.

Kul om du går vidare, på 1990-talet gjorde jag nästan ett helt paket med funktioner i Matlab. Hade dock varit bättre att satsa på C som hade varit flexiblare på minneshanteringen vilket var det stora problemet då.

Lars

[megmar]

Jo, mycket olika tekniker som ska samverka för att få till en bra bild. Min tanke är att man lär sig mycket när man "bygger själv". Tänker att det är lite som dom som bygger eget teleskop eller slipar spegel. Först gäller det att läsa på ordentligt, lära sig kontrollera resultat med olika tester, sen planera projektet och utföra osv. Slutar säkert med att man får en helt annan uppskattning sedan för de färdiga produkterna

Angående helpixel align så tyckte jag också det lät skumt, men blev bättre resultat än jag förväntade mig. Sen Craig Stark,... hans ord väger ju tungt.
Hursomhelst så finns det situationer iaf för mig när jag bara vill ha en snabb stackning för att kontrollera vad man fått så kanske kan användas lite som en "preview"?

Ang minneshantering som du skrev om Lars, där har ju mycket förändrats. Drog in alla 213 TIFF bilderna i minnet utan några som helst problem
Nås gränsen så skulle man annars kunna splitta bilderna i block om tex 256x256 pixel och stacka ett block i taget.

[hbar]

Hej Magnus

Jag har använt nebulosity många år och inte känt något problem med grynighet men det beror nog lite på hur mycket kameran översamplar i förhållande till seeingen. Använder man dslr så är ofta pixlarna så små (och många, dessutom redan översamplade i debayer) att även vid kort brännvidd så kommer rådata att begränsar.

När jag kör med ccd och skall försöka pressa ur max så använder jag ibland drizzle funktionen i nebulosity. En lite snabbare variant av denna skulle vara att skippa interpolationen utan bara översampla en faktor två och sen köra pixelbaserad stackning. Därefter kan man köra tillbaka den till ursprungliga upplösningen med vanlig binning. Uppsamplingen görs bild för bild innan stackning så det är bara resultatet och en råbild som blir 4ggr större.

Det tar 4ggr längre tid men jag tror att det ändå är snabbare än interpolation. Jag har funderat på att göra något sådant som kunde ligga direkt i den cpu som samlar in bilden eller om man skall försöka få till live-stacking i en r-pi. Derotationen är nog det mest cpu krävande om man inte skriver en bra algoritm för detta.

Hoppas du får ihop något, lite synd bara att du valt c# och låst dig till Microsoft.

/Håkan

[megmar]

En lite snabbare variant av denna skulle vara att skippa interpolationen utan bara översampla en faktor två och sen köra pixelbaserad stackning. Därefter kan man köra tillbaka den till ursprungliga upplösningen med vanlig binning.

Hmm, ja blir en slags "halvpixel" align då. Men som sagt man kan fortsätta köra den snabba simpla stackningen så det är ju bra. Ska fundera på detta. Tror jag skulle kunna uppsampla "live" för resp grundpixel och bara låta resultat bitmappen vara i dubbla upplösningen. På det sättet slippa slösa minne genom att dubbla upplösningen på alla delframes tänker jag.

Hoppas du får ihop något, lite synd bara att du valt c# och låst dig till Microsoft.

mja jag vet inte. Det där (inlåsningen) stämde kanske för 10 år sedan, men C# kan man idag köra på alla stora plattformar utan begränsningar. Det mesta av .NET koden inklusive kompilatorer, runtime, base classes etc är öppen källkod på github idag: https://github.com/dotnet" onclick="window.open(this.href);return false;
Microsoft har verkligen gjort en kovändning när det gäller sin inställning till open source, Linux mm så tycker dom är värda mycket beröm för detta.
Men du har rätt i att C eller C++ hade varit ännu mer portabelt. Tyvärr är jag lite ringrostig på det och mycket mer produktiv i C# så fick bli det språket

[AstroFriend]

AIJ, AstroImageJ som jag använder är baserat på Java och plattformsoberoende. Klarar även 64 bit. Jag hade trott det skulle bli alldeles för långsamt, men går tillräckligt snabbt för att jag inte skall slänga ut datorn genom fönstret.

Jag gick en kurs i C++ på 1990-talet och då som ett projekt arbete gjorde jag en grund för ett astro redigerings program. 32 bit/ pixel, bara det mest grundläggande som att öppna och spara filer samt rotera och sidskifta och kanske det var något mer.

Skall man få en bra aligning behöver man:
Sidskifta
Rotera
Skala
Samt högre ordning av skalning för att hantera distorsion, typ A*x^0 + B*x^1 + C*x^2 + D*x^3

Dessutom behöver i regel de 3 färgerna alignas relativt varandra.

Det jag gjorde i Matlab kunde hantera ovan och lite till.

Man får ta till en del knep, speciellt när man skalar upp, det uppstår då "hål" i nya bilden, man får ta det bakvägen så att säga för att undvika detta.

Här är grunden för matris operationerna:
https://en.wikipedia.org/wiki/Transformation_matrix" onclick="window.open(this.href);return false;

Handlar mycket om matris funktioner, det finns färdiga att ladda ned till C antar jag. Jag har byggt upp det med matriser men blir väldigt komplext och svårt med minneshanteringen beroende på vilket program. Letade i mitt arkiv om jag hade något kvar av detta, tyvärr var det raderat sedan många datorbyten sedan. Man kan inte använda matriser funktioner fullt ut vid olinjära funktioner, jag gjorde någon special där som jag glömt bort. Olinjära avbildningar blev vid aligning av optik med distorsion. Vanlig affine klara bara linjära avbildningar.

Allt detta lärde mig otroligt mycket och synd jag aldrig fortsatte med C utvecklingen, då hade jag haft ett färdigt astro program som jag kunnat anpassat helt efter mina och andras behov.

Så om du gör detta i C eller kanske Java så kommer du som du skriver ha en helt annan förståelse för detta och en insikt hur komplext det blir när man kommer ner på djupet.

/Lars

[hbar]

Ja det är ju i centroid beräkningen av ref stjärnorna du tar med en binär decimal till. Sen blir detta en möjlig halvpixel extra offset i x,y led.

Det är jag som tyvärr inte hängt med. Jobbade tidigare mycket med Borlands turbo/delphi pascal (vars runtime net till stor del baseras på). Tyckte mycket om detta men de sista 10 åren med windows mm har jag inte orkat hänga med. Skall bli roligt när jag kan trappa ner på försörjningsbehovet o börja ta upp lite mer sådan programmering.

Trevligt att c# har blivit så öppet. Behöver bla skriva en ascom driver för några ccd kameror o då är ju c# ett alternativ.

/Håkan

[AstroFriend]

Jag gjorde i regel som så att från det som blir den nya alignade sub bilden tittade jag tillbaks på original bilden pixel för pixel och hämtade värdet från de fyra pixlar och gjorde en bilinear av bildning till den nya pixelns värde. Men det finns flera specialfall där man får göra på annat sätt.

Lars

[megmar]

En lite snabbare variant av denna skulle vara att skippa interpolationen utan bara översampla en faktor två och sen köra pixelbaserad stackning. Därefter kan man köra tillbaka den till ursprungliga upplösningen med vanlig binning.

Jag vet inte om du insåg det själv Håkan, men det du beskriver ovan (om man hoppar över sista steget, binning) är troligen en Drizzle 2x med parametern pixfrac = 0.0 !!
Som bekant var det i samband med bildbehandling för Hubble telskopet som "Drizzle" tekniken uppfanns. Dom har ett program AstroDrizzle som är väldokumenterat, bla ett avsnitt som handlar om själva algoritmen och dess parametrar: http://documents.stsci.edu/hst/HST_over ... tml#586267" onclick="window.open(this.href);return false;

Tyckte det här avsnittet var spännande:

Using an even finer scale or pixfrac may be advantageous when one has large numbers of images and one wishes to obtain the best possible SNR on point sources (the PSF is convolved in quadrature with both the final scale and pixfrac). Thus, the Hubble Ultra Deep Field (Beckwith et al. 2006) used a scale equal to 0.4 of the original pixel and a pixfrac of zero! Since the addition of the effect is in quadrature, however, and the original pixel and PSF are substantially larger than the pixfrac, the main effect of using such a small pixfrac is to entirely eliminate correlated noise (See Section 2.3.2). However, using a smaller pixfrac also reduces the ability of the eye to detect low surface brightness features in the image.

Även interpolationen beskrivs. Man kan ju köra med "kvadrat", men pixfrac = 0 kommer tvinga fram "point" kernel..

Shape of kernel function
The default turbo kernel function is only used in the “drizzle separate images” step, not in the final drizzling step. It specifies the form of the kernel function used to distribute flux onto the separate output images. Several options are available:
•square: original classic drizzling kernel which maps each corner of the input pixel (scaled in size by the driz_sep_pixfrac parameter) to its position in the output image.
•point: a point so each input pixel can only contribute to the single pixel that is closest to the output position. It's equivalent to the limit pixfrac-->0 and is very fast.
•gaussian: this is a circular gaussian with FWHM equal to the value of pixfrac, measured in input pixels.
•turbo: this is similar to the square kernel, but the box is always the same shape and size on the output grid, and always aligned with the X and Y axes. This results in a significant increase in speed.
•tophat: the kernel is a circular "top hat" shape of width pixfrac. Flux from the input pixel gets distributed only to the output pixels within pixfrac/2 of the output position.
•lanczos3: a Lanczos-style kernel extending 3 pixels from the center. The Lanczos kernel is a damped bounded form of the sinc interpolator and is very effective for resampling single images when drizzing is in the native scale and pixfrac=1. It leads to less resolution loss than the other kernels, and also less correlated noise in outputs. It is however much slower. It should never be used for pixfrac != 1.0 and is not recommended for scale != native scale.
NOTE: The default value for this parameter is turbo since it is much faster than square, and it is quite satisfactory for the purposes of generating the median image.

[hbar]

Tack för länken. Har inte grävt i det matematiska men vet att det togs fram för Hubbles bildbehandling. Eftersom vi måste fota genom en atmosfär som rör om o har monteringar som hoppar runt så blir behoven lite annorlunda.

Har en gammal apogee 7 kamera liggande som jag tänkte fixa ny elektronik till. Sensorn är trevlig (bakbelyst site 502a) men som har lite låg upplösning (512x512) dock ett qe som få. Pixlarna är 24x24um så en upsampling till 1024x1024 skulle vara önskvärt. Kan vara kul att se vad den kan ge i kortvågigt ir, den har ett qe på över 50% vid 900nm.

/Håkan

[AstroFriend]

Kul om ni gör ett försök att få till egna Drizzle funktioner. Jag vill minnas att Nasas egna Drizzle är ersatt med något annat och att det också fanns någon gammal bug i deras Drizzle. Kommer tyvärr inte ihåg hur namnet var på den nya motsvarande funktionen, men den var mycket mer avancerad.

Har faktiskt idag tittat på det själv, höll ju på i Matlab för drygt 20 år sedan, men just detta hann jag aldrig börja med, ja det hade nog inte gått med den tidens datorers minneslösa uppsättningar. Nu löser jag det i AstronomyImageJ om det går utan alltför stora programmeringsinsatser, fördelen är ju att det är i Java och blir plattforms oberoende som jag skrev tidigare. Tror dock grunderna redan finns där och att det räcker med några makron som kopplar ihop funktionerna. Det blir en linjär funktion med rotation och stretch. Finns också åtminstone en färdig funktion, men den är mer specialiserad mot ytobjekt och inom mikroskopin.

/Lars

[megmar]

Det går långsamt framåt
För att lyckas med automatisk aligning så måste jag först detektera misstänkta stjärnor i varje sub och har nu kommit så långt att den detekterar sådana hyfsat väl. Nästa steg blir att beräkna "Center of Mass" för respektive stjärna så man får varje stjärnas position med subpixel precision.

[megmar]

Testade stjärndetektorn på en gammal Canon 500D bild (av M106) som jag hade bara för att se hur robust algoritmen är.
Lade även till ID bredvid varje stjärna i Debug vyn.

[hbar]

Trevligt att se att det går framåt.

Jag förmodar att du tänkt på det men en sak som jag saknat är ett bra verktyg för att sortera ut de bilder som har för dåligt HFR (Half Flux Radius). Nebulosity har en sorterings-graderings funktion men den fungerar inte bra. Man behöver titta på flera stjärnor o då både starka o svaga. En kort misalignment (vindpust) syns lätt på en stark men kanske är för liten för att registreras då stjärnans diameter är för stor. En liten men långvarig syns på en svag.

Bara ett sådant verktyg med bra kontroll skulle vara mycket trevlig att kunna köra ensamt.

/Håkan

[megmar]

Jag förmodar att du tänkt på det men en sak som jag saknat är ett bra verktyg för att sortera ut de bilder som har för dåligt HFR (Half Flux Radius)

Jo absolut, har saknat det själv!
DSS som jag mest använder kan visa nåt slags medeltal för FWHM, men den är inte heller tillförlitlig. Kan ibland se tydligt avlånga stjärnor som ändå får hyfsat FWHM värde tyvärr. Har läst på lite i vetenskapliga artiklar och ofta mäter man även "shape" på stjärnorna, dvs hur nära dom ligger en optimal cirkel i utseende. Kan ju va intressant, men just nu ser närmaste roadmap ut så här:

1. Beräkna CoM (Center of Mass) med sub pixel accuracy för respektive sjärna
2. FWHM, HFD (HFR)
3. Align

Både (2) och (3) är beroende av robust lösning på (1) så måste lösa den först.