- This topic has 76 replies, 8 voices, and was last updated 9 years, 7 months ago by
.
-
Posts
-
Misschien is de noise dan wel hetzelfde, bij mij staan de witbalans opties uit en met mijn sky flats krijg ik toch een rood boost en een blauw onderdrukking … of heb ik iets gemist in deze lange thread …
ik sla altijd op in fit, als ik Neff gebruik dan werkt platesolving niet meer en 2 keer 36MP bewaren wordt wat veel …
Misschien is de noise dan wel hetzelfde, bij mij staan de witbalans opties uit en met mijn sky flats krijg ik toch een rood boost en een blauw onderdrukking … of heb ik iets gemist in deze lange thread …
Zonder vooruit te willen lopen op de feiten: mogelijk heb jij te maken met hetzelfde euvel als JP Durman (aangezien jij ook SGP gebruikt om de data als FITS weg te schrijven).
Ik heb SGP nog maar net, maar al voor deze thread besloten alles als CR2 op te slaan. Ik vond het juist heerlijk dat SGP previews en allerhande zaken als autofocus, op de CR2 files kon doen (als ik mij niet vergis). Dat was de enige reden dat ik met INDI in fits opsloeg, want zo dicht mogelijk bij de bron blijven, daar streef ik altijd naar.
Er komen antwoorden binnen op het draadje van Christian v d Berge op het PI forum:
“any process that can use “format hints” (like ImageIntegration or ImageCalibration) can override the settings in DSLR_RAW. this is how BatchPreProcessing overrides the settings in DSLR_RAW to be correct for calibration of DSLR images.”
Inderdaad en het BatchPreProcessing script doet dit ook. Wat dan wel gek is, @bula, ik had die hints gewoon aanstaan voor mijn flats. Dus hoe kan dat dan alsnog fout gaan.. enige wat ik altijd doe is eerst een format conversion..
@supernov, dat is voor mij eigenlijk niet in te schatten vrees ik, ik weet niet wat er intern in Pixinsight gebeurt en ik heb ook niet dusdanig ervaring in werken met Pixinsight dat ik een inschatting van waarde kan maken.
Het is aan de Pixinsight gebruikers zelf om dit soort vreemd gedrag te onderzoeken en aan te kaarten bij de ontwikkelaars als je het verdacht vindt.
Okee, zoals beloofd op het astroforum facebook draadje:
Ik heb de data van @mauricetoet verwerkt in mijn programma waarbij witbalans niet is genegeerd in het calibratie proces.
Ik heb in wel 4 modules van mijn programma code moeten aanpassen, om uberhaupt calibratie te kunnen doen waarbij de witbalans settings van de CR2 files niet genegeerd worden. (In mijn programma kan je in het calibratieproces als gebruiker gewoon geen fout maken, door verkeerde settings. Het is een fail-safe implementatie met speciale raw image loaders in het calibratie proces, dit zijn dus andere loaders dan die voor het laden van een CR2 light worden gebruikt.)
Anyway, om welke data gaat het;
25x bias ISO 200 voor bias calibratie van de flats: deze data heeft de volgende camera witbalans voor R, G1, G2, B in de CR2 makernote staan
1362.0 1026.0 1026.0 1578.0 dit moet worden gedeeld door 1024, afgerond getoond- > 1.33 1,00 1,00 1,54
25x bias ISO 1600 voor bias calibratie van de light frame: heeft dezelfde WB : – > 1.33 1,00 1,00 1,54
19x flats ISO200 met WB -> 1.33 1,00 1,00 1,54
De light heeft zelf een andere WB, namelijk -> 1,24 1 ,00 1,00 2,22 ( maar dit heeft verder geen invloed op de calibratie natuurlijk, want wit balans wordt pas toegepast na calibratie van de raw sensor data, zoals het hoort.)
De masterbias frames zijn gemaakt met de WB aan, ter vergelijking de statistiek van de masterbias ISO200 zonder WB
Zonder WB:
MEAN-R = ‘1,024E+03’ / mean of channel-R
MEAN-G1 = ‘1,024E+03’ / mean of channel-G1
MEAN-G2 = ‘1,024E+03’ / mean of channel-G2
MEAN-B = ‘1,023E+03’ / mean of channel-B
MED-R = ‘1,024E+03’ / median of channel-R
MED-G1 = ‘1,024E+03’ / median of channel-G1
MED-G2 = ‘1,024E+03’ / median of channel-G2
MED-B = ‘1,023E+03’ / median of channel-B
SIGMA-R = ‘1,661E+00’ / standard deviation of channel-R
SIGMA-G1= ‘1,635E+00’ / standard deviation of channel-G1
SIGMA-G2= ‘1,652E+00’ / standard deviation of channel-G2
SIGMA-B = ‘1,629E+00’ / standard deviation of channel-B
NOISE-R = ‘1,646E+00’ / MRS gaussian noise estimate of channel-R
NOISE-G1= ‘1,633E+00’ / MRS gaussian noise estimate of channel-G1
NOISE-G2= ‘1,653E+00’ / MRS gaussian noise estimate of channel-G2
NOISE-B = ‘1,629E+00’ / MRS gaussian noise estimate of channel-Ben de statistiek van de masterbias 200 met WB
MEAN-R = ‘1,362E+03’ / mean of channel-R
MEAN-G1 = ‘1,025E+03’ / mean of channel-G1
MEAN-G2 = ‘1,025E+03’ / mean of channel-G2
MEAN-B = ‘1,577E+03’ / mean of channel-B
MED-R = ‘1,362E+03’ / median of channel-R
MED-G1 = ‘1,025E+03’ / median of channel-G1
MED-G2 = ‘1,025E+03’ / median of channel-G2
MED-B = ‘1,577E+03’ / median of channel-B
SIGMA-R = ‘2,168E+00’ / standard deviation of channel-R
SIGMA-G1= ‘1,727E+00’ / standard deviation of channel-G1
SIGMA-G2= ‘1,745E+00’ / standard deviation of channel-G2
SIGMA-B = ‘2,484E+00’ / standard deviation of channel-B
NOISE-R = ‘2,158E+00’ / MRS gaussian noise estimate of channel-R
NOISE-G1= ‘1,726E+00’ / MRS gaussian noise estimate of channel-G1
NOISE-G2= ‘1,741E+00’ / MRS gaussian noise estimate of channel-G2
NOISE-B = ‘2,480E+00’Je ziet duidelijk de multipliers van de WB naar voren komen in deze waardes (zoals verwacht).
Hetzelfde zie je natuurlijk bij de andere masterbias en de masterflat.
De masterflat wordt bias gecalibreerd. Door de WB setting, wordt er van R en B veel te veel afgetrokken. Zoveel dat in dit geval het blauwe kanaal in de flat er zwaar onder lijdt, een deel van blauw in de flat verdwijnt links uit het histogram door de bias subtractie.
Oftewel de flat calibratie in blauw zal wel een ramp zijn nu…
De light frame wordt bias gecalibreerd, hier wordt dus ook te veel van R en B afgetrokken. Daarna wordt de data gedeeld door de (Wit balans gecalibreerde) flat waarbij blauw al vrijwel dood is gemaakt om het maar zo te zeggen ;-( .
Dit is de gecalibreerd light zonder de Wit Balans en dus juist gecalibreerd.
Dat is de gecalibreerde light met Wit Balans en dus helemaal fout… (zelfde stretch, saturatie, contrast parameters)
Als we naar de noise kijken na data normalisatie voor lokatie en dispersie, zie ik ook wel rare dingen gebeuren.
Calibratie zonder Wit Balans
R noise : 0,0035
G noise: 0,0038
B noise: 0,0045
Caibratie met Wit Balans
R noise: 0,0029 noise afname? (wordt verklaard door foute data normalisatie omdat het rode kanaal helemaal niet vlak is geworden door de flat calibratie tov de data die juist is gecalibreerd, dus dispersie wordt overschat met 20% en daardoor gaat noise 20% omlaag na normalisatie)
G noise: 0,0038 (onveranderd, groen had multipliers van 1, dus dat verwacht je ook)
B noise: 0,0443 factor 10 slechter ( 1000% toename noise ), het blauwe kanaal is gewoon helemaal om zeep geholpen… en ook hier is de dispersie normalisatie in feit niet meer te doen tov de goed gecalibreerde data.
Je ziet ook aan de Wit Balans gecalibreerde light dat het blauwe licht er gewoon uit is en dat flat calibratie op deze manier echt niet kan.
Deze resultaten zijn toch ook weer nuttig voor verder inzicht, de Wit Balans calibratie is overduidelijk fout. Zo fout dat ik eigenlijk dit geen verklaring meer kan vinden voor de vastgestelde calibratie problemen bij veel mensen in Pixinsight.
Ik vrees dat de calibratie resultaten op deze manier dusdanig snel dramatisch worden, dat de witbalans setting in mijn ogen waarschijnlijk niet de (enige? ) verklaring kan zijn voor de afwijkende calibraties in Pixinsight die bij meerdere gebruikers worden vastgesteld.
Van alle data (meerdere formaten, FITS, CR2, NEF), van meerder fotografen, die ik heb gecontroleerd die gecalibreerd is in Pixinsight is de data van @mauricetoet de enige data die goed is gecalibreerd volgens mij.
Hoe dit komt, blijft voor mij nu toch onverklaarbaar. Ongetwijfeld heeft het een oorzaak, maar ik weet niet welke. Deze test dwingt mij opnieuw om mijn opvatting te herzien.
Ik heb inmiddels erg veel van mijn tijd gespendeerd aan een probleem in een programma wat ik zelf niet gebruik ;-) (en ook niet zal gebruiken) en ik denk dat het verder een zaak is voor de pixinsight gebruikers zelf om tot de bodem hiervan te komen. Ik heb graag dit onderzoek gedaan, want het is heel leerzaam geweest ( en het heeft zelfs een bugje in mijn eigen programma opgelost ;-) )
Ik vind het zeker jammer dat er, in mijn optiek, toch geen goede verklaring is gevonden voor calibratie problematiek in Pixinsight…
De Wit Balans calibratie frames en de gecalibreerde light zijn hier te vinden:
Ik vind het zeker jammer dat er, in mijn optiek, toch geen goede verklaring is gevonden voor calibratie problematiek in Pixinsight…
Waarschijnlijk mis ik het punt in de details van alle posts hier, maar was de calibratie zonder WB niet gewoon goed? Dacht dat ik je dat eerder zag noemen. Wat is dan de ‘calibratie problematiek’?
Hoi @chrisvdberge, deze discussie is begonnen op astroforum.nl. Zie:
Unruhe en ik hebben een samenwerkingsverband en hij had een setje data verwerkt in Pixinsight. Ik heb daarna diezelfde data verwerkt in mijn programma. Allereerst valt op dat Pixinsight je data compleet veranderd in het flat calibratie proces. Een groene sub kan opeens knalrood worden en de histogrammen van de gebruikte masterflat heeft dit als oorzaak . De kleurkanalen ten opzichte van elkaar krijgen compleet andere multipliers. In dit draadje laat ik in de openingspost zien, dat je ook flat calibratie kan implementeren die de kleur van de light min of meer hetzelfde houdt, voor en na, flat calibratie. Sterker, in mijn implementatie doet de kleur van je flat er niet toe om dezelfde resultaten te krijgen. Dit is een discussie die op veel fora voert internationaal blijkbaar.
Erger is dat in sommige gevallen de flat calibratie in pixinsight lijkt te werken als een noise injector. De data van Unruhe waren fits files uitgepoept door SGP van een Canon 60D. Voor als nog is er geen verklaring waarom er noise injectie plaats vindt. Deze noise injectie is ook vastgesteld bij @supernov (Vincent Groenewold) en @yves (Yves van den Broek) kan er ook over meepraten. Ik kan je de stack uit Pixinsight en mijn programma laten zien, dan kan je ze zelf vergelijken als je wil?
@bula Ben dan vooral benieuwd hoe ze gecalibreerd hebben en of dit dan dus ook gebeurd als je ‘gewoon’ Batch Preprocessing gebruikt (en dus NIET de WB setting toepast). Geldt natuurlijk ook voor de manier waarop de MasterFlats gemaakt zijn
Ikzelf heb het in elk geval nooit gemerkt, maar wellicht zie ik het compleet over het hoofd :P@chrisvdberge, in het geval van Unruhe en ook Vincent Groenewold zijn de calibratie paden hetzelfde geweest kan ik je verzekeren.
Dit is een screenshot van M31 van @supernov een stack gemaakt met mijn programma, onderaan zie je wat statistiek staan
Dit is de stack die Vincent zelf heeft gemaakt in Pixinsight
Dit zijn de 2 stacks genormaliseerd met elkaar voor lokatie en dispersie, zodat een noise, SNR vergelijking zinvol is. Beide screenshots is dus de data genormaliseerd met elkaar met vervolgens een identieke stretch op de data. Je ziet visueel in de stack van Pixinsight duidelijk dat er wat met blauw gebeurd in de rechter onderhoek.
Hier zie je dat het blauwe kanaal in de stack van Vincent om zeep wordt geholpen. De noise ligt in die stack 50% hoger dan in mijn stack. Bij mijn stack zie je dat de noise in R,G,B ook vergelijkbaar blijft. En Pixinsight lijkt het verband tussen de kanalen zoek.
( Mijn stack heeft een afwijkende vorm, door toepassen van echte optische vervormings correctie.)
Wat ik mij kan voorstellen is dat wanneer de RAW-bestanden niet in PixInsight worden geconverteerd naar FITS-bestanden, maar door een ander programma (zoals bij unruHe en Yves), PixInsight de DSLR RAW-bestanden niet als zodanig herkent of daar op zijn minst op controleert. De instellingen onder DSLR_RAW hebben dan geen effect. Evenmin hebben de zogenaamde “Format hints” in het ImageCalibration dan effect. (De Format hints “raw cfa” zitten ingebakken in het BatchPreprocessing script).
Daar kan weldegelijk het verschil in zitten ja, ik heb bijvoorbeeld ook geen RAW Light bestanden omdat ik destijds niet wist hoe dit beiden te bewaren in INDI (kan dus wel). Voortaan wel doen dus, de lights die ik heb gebruikt zijn dus door GPhoto omgezet naar fits.
- You must be logged in to reply to this topic.