- This topic has 76 replies, 8 voices, and was last updated 7 years, 6 months ago by
.
-
Posts
-
@Mauricetoet, ik heb toch een probleem met de bias. De geleverde masterbias is van een voor mij onverklaarbaar formaat.
De masterbias zou qua dimensies overeen moeten komen met de volledige sensor van de Canon 5d mark II:
De volledige sensor is 5792×3804, en een normale opname heeft een crop hieruit van 5616×3744 zoals je weet.
De masterbias heeft een dimensie, van 5634×3752, dit is vreemd. Enige verklaring voor mij is dat dcraw een shortcutje neemt en niet netjes is in dit opzicht.
Hier 2 screenshotjes uit de metadata van een van je flats, die laten zien wat het zou moeten zijn:
De IFD1, die bij CR2s dezelfde dimensie heeft als de raw crop, kijk naar ImageWidth en ImageLength tags
En de makernote, kijk naar tag SensorInfo, 2de en 3de getal
Dit gebeurt niet altijd, maar in dit geval kan ik dan de masterbias niet correct converteren, ik moet gaan gissen met hoeveel pixels ik moet gaan schuiven, dat is ondoenlijk.
Ik kan mijn resultaat tonen zonder gebruik van bias, of je moet toch even enkele bias op iso 200 en iso 1600 maken…
Mabula
Ik weet niet of dcraw dat doet of dat PixInsight zelf de dimensies van de afbeelding aanpast. Dat gebeurt in elke geval voor alle CR2-bestanden die ik in PI open.
Hierbij opnieuw twee WeTransfer links. De eerste bevat 25 biasframes op ISO 200, de tweede bevat 25 biasframes op ISO 1600. Vers van het land…
Bedankt Maurice, ik ga ermee aan de slag ;-)
Ik zie inderdaad dat er wel correct de sensor dimensions worden aangegeven. Waarom PI en dcraw samen voor een afwijkende image size gaan weet ik eigenlijk niet. Ik weet wel vrij zeker dat dit door dcraw komt. Het filter pattern RG/GB is namelijk ook niet correct. Je krijgt wel de juiste data interpretatie en interpolatie van dcraw, maar hier neemt dcraw zeker een shortcut. Ik heb dit ook al vastgesteld bij andere camera’s zoals de Canon 60D. Daar neemt dcraw dezelfde shortcut namelijk. Het echte filter pattern is bij jouw camera en de 60D GBRG, (dan klopt het namelijk met de volledige sensor). Je ziet het ook aan de image size hoogte. Dat is oneven, terwijl de sensor even hoogte heeft. Om het filter patroon dan te laten kloppen zegt dcraw dat het RGGB moet zijn en dat klopt niet.
Maar goed, nogal off-topic ;-)… Ik hoop later vanavond plaatjes te plaatsen van jouw gecalibreerde sub met mijn programma.
Wacht effe, is dit specifiek voor de 60D of geldt dit dan voor alle Canon sensoren, zoals die in mijn 6D? Zal wel niet toch, daar staat overal bij dat het RGGB is in de specificaties.
Wacht effe, is dit specifiek voor de 60D of geldt dit dan voor alle Canon sensoren, zoals die in mijn 6D? Zal wel niet toch, daar staat overal bij dat het RGGB is in de specificaties.
Ik heb van behoorlijk veel Canon camera’s de CR2s getest tijdens ontwikkeling. De meeste Canon DSLRs hebben RGGB inderdaad, de Canon 6D is ook RGGB . Hier een screenshot uit de CR2 converter, een matrix met model specifieke waardes. De column waarin je {0,1,1,2} is de CFA filter kolom. o,1,1,2 is RGGB dus 1,2,0,1 is GBRG,( ik moet binnenkort weer even wat nieuwe modellen erbij zetten.)
http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/CanonCameraMatrices.jpg
Bij deze de resultaten van de data van @mauricetoet middels mijn programma, ik heb net zoals Maurice, 4 screenshots gemaakt.
– Alle data wordt lineair geinterpreteerd zonder witbalans
– de light en gecalibreerde light worden getoond met een identieke zwakke DDP stretch
– de flat en masterflat worden getoond met aangepast zwart en wit punt en een gamma conversie om de vignettering en stof goed te zien
1) oorspronkelijk lightframe, CR2
2) de oorspronkelijke lightframe, gecalibreerd met bias-calibrated MasterFlat en MasterBias
3) een enkele flat, CR2
4) de masterflat frame vanuit de bias gecalibreerde flats, let op! omdat de masterflat de hele sensor corrigeert zitten hier de volledige raw borders nog omheen, daarom zie je in het image viewer panel links opeens een zwart balk, als je naar de dimensies van de bestanden kijkt zul je dus zien dat de masterflat de sensor dimensies heeft.
Alles hier te downloaden:
http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/MauriceToet/
gecalibreerde light – cal-IMG_0421.fits
MasterBias iso200 – MB-ISO_gain_200.0-exp_1.25E-4s-25subs-CANONEOS5DMARKII-NR-avg.fits
MasterBias iso1600 – MB-ISO_gain_1600.0-exp_1.25E-4s-25subs-CANONEOS5DMARKII-NR-avg.fits
MasterFlat-bias calibrated – MF-ISO_gain_200.0-exp_1.0s-CANONEOS5DMARKII-NR-avg-NB.fits
Duidelijk is dat mijn gecalibreerde light, vergeleken met de ongecalibreerde light, qua ADU waardes vergelijkbaar blijft en dat de kleur kanalen vrijwel gelijk blijven. Bij PI wordt de gecalibreerde light opeens helemaal blauw.
Voor mij is nu de grote vraag hoe mijn gecalibreerde light zich qua lokatie, dispersie, noise en SNR verhoudt met de gecalibreerde light die uit Pixinsight komt. Kan je de gecalibreerde light uit Pixinsight delen @mauricetoet ?
Bedankt voor de moeite @bula! Om appels zo goed mogelijk met appels te kunnen vergelijken heb ik het lightframe (nr. 0421) opnieuw gekalibreerd met een masterbiasframe verkregen uit de 25 “verse” ISO 1600 biasframes en een masterflatframe verkregen uit de flatframes die op hun beurt gekalibreerd waren met de 25 verse ISO 200 biasframes.
(Voor de bewerking van dit object heb ik de lightframes destijds gekalibreerd met een masterbiasframe samengesteld uit 100 “ISO 1600 biasframes”, een masterflatframe samengesteld uit dezelfde 19 flatframes, maar dan gekalibreerd met een masterbiasframe verkregen uit 100 “ISO 200 biasframes”, en met een (door PI geschaalde (!)) masterdarkframe samengesteld uit 119 darkframes).
@mauricetoet, bedankt en graag gedaan! Maar ik moet jouw bedanken, ik zie nu in mijn cr2 converter een klein bugje, de zwart en wit waardes werden geclipped in mijn lineaire en raw interpretatie. Dat moet natuurlijk niet… dus heb ik meteen gefixt, misschien had je al aan mijn gecalibreerde light gezien dat die niet helemaal goed is in de hoeken. Ik laat zo direct een nieuwe zien en die zal ik ook naar de folder op mijn server uploaden. Is wel cruciaal dus ik ben blij dat ik door jouw data hier tegen aanloop ;-).
In de 5D Mark II wordt normaal de zwart waarde en de wit waarde geclipped. Ik zie een zwarte clip op adu 950 en een witte op 15600, wat dus je data diepte normaal iets verkleint.
Okee, eerst een paar nieuwe screenshots want vanwege de bug waren de histogram waardes ook niet goed…
1) uncalibrated Light
2) calibrated light
3) single uncalibrated flat
4) master flat, bias-calibrated
Hier is dan mijn vergelijking tussen de gecalibreerde light gemaakt door @mauricetoet in Pixinsight en de gecalibreerde light in mijn programma. ( @keesscherer, @supernov ).
Alles te downloaden vanuit nieuwe folder, dus ook de master calibratie frames:
http://www.bulapedia.nl/images/flatCalibrationUsingDifferentFlats/MauriceToet/correct/
Ik heb voor de vergelijking de gecalibreerde lights genormaliseerd voor lokatie en dispersie, zodat een noise vergelijking zinvol is.
1) een auto ddp-stretch van de gecalibreerde light, waar bij de achtergrond is geneutraliseerd
2) om de flat calibratie te controleren heb ik de 2 gecalibreerde lights uit de twee programma’s identiek zwaar gestretcht, met saturatie en contrast boost. Op die manier zie je duidelijk of er mogelijk verschillen te zien zijn. Ik zie geen enkel verschil geloof ik…
a) gecalibreerde light uit Pixinsight
b) gecalibreerde light uit mijn programma
3) Als laatste de verschillen in noise, i.t.t. data van andere astrofotografen die met Pixinsight werken, zie ik tussen de 2 gecalibreerde lights geen noise verschillen tussen de kanalen. Dus het resultaat tussen Pixinsight en mijn programma is identiek te noemen in dit geval. Dit is goed nieuws en ik moet denk ik terug nemen dat in Pixinsight de flat-calibratie slecht is. Ik denk dat de noise problemen van de andere fotografen komen door niet juiste instellingen in de RAW conversie en dan met name het niet uitzetten van de wit-balans. Een andere verklaring zie ik niet.
De noise waardes na data normalizatie ( lokatie en dispersie), de gecalibreerde light uit mijn programma is genomen als referentie.
Waardes in genormaliseerde 0-1 range
Kanaal Pixinsight Mabula
Rood 0,0035 0,0035
Groen 0,0038 0,0038
Blauw 0,0045 0,0045
Geen enkel verschil ;-)
Mogelijk hebben we bij deze dan eindelijk een verklaring voor de slechte flat calibratie die sommige mensen ondervinden in Pixinsight.
( @mauricetoet, de correcte gecalibreerde light vanuit mijn programma is:
Ah! Interessant, dus die instellingen hebben inderdaad effect. Toch fijn te weten, maar denk niet dat ik dit ooit had geweten als je niet dusdanig grondig was met onderzoeken. Echt heel waardevol jouw inbreng @bula.
Prachtige analyseresultaten @Bula! Mooi dat je als bijkomstigheid een bugje hebt kunnen traceren in jouw cr2 convertor. M.b.t. de grotere dimensies van het outputfile: dankzij Google kwam ik op het spoor dat dcraw de opname iets vergroot om artefacten aan de randen van de CFA bij conversie te voorkomen. Het fijne weet ik er niet van.
Als laatste de verschillen in noise, i.t.t. data van andere astrofotografen die met Pixinsight werken, zie ik tussen de 2 gecalibreerde lights geen noise verschillen tussen de kanalen. Dus het resultaat tussen Pixinsight en mijn programma is identiek te noemen in dit geval. Dit is goed nieuws en ik moet denk ik terug nemen dat in Pixinsight de flat-calibratie slecht is. Ik denk dat de noise problemen van de andere fotografen komen door niet juiste instellingen in de RAW conversie en dan met name het niet uitzetten van de wit-balans. Een andere verklaring zie ik niet.
Dat is zeker goed nieuws! Het blijkt maar weer dat de gebruiker van een programma de zwakste schakel is. Ik kon mij al haast niet voorstellen dat PixInsight tijdens het kalibratieproces bochten afsnijdt. Er zitten heel wat knappe koppen achter dat programma (die elkaar ook scherp houden) en het programma is in de loop der jaren heel wat volwassener geworden. Hou me ten goede: dat betekent uiteraard niet per definitie dat het programma geen fouten bevat.
Dank je @mauricetoet en graag gedaan, nog even zwaar off-topic:
wat de afwijkende image size betreft, vind ik na googlen mogelijk hetzelfde wat jij tegenkomt:
Van het INDI forum:
http://www.indilib.org/forum/ccds-dslrs/471-canon-wrong-raw-image-dimension-pixel-size-solved.html
“Dcraw is not enlarging your image; it just doesn’t crop
the edges like Canon’s firmware and software do. They do
this because hardware interpolators have problems with edges,
whereas dcraw switches to a different algorithm at the edge.”De edge problems van hardware interpolators zullen er natuurlijk alleen zijn aan de rand van de sensor. Verder kan je altijd croppen ten opzichte daarvan. In mijn converters heb ik enkel een edge problem bij het debayeren van de volledige sensor, daarna doe ik de crop naar de normale image size. De groote van de juiste image size van de raw data wordt gegeven door andere getallen die ook in de sensorInfo tag zitten in de makernote van de CR2 file. In feite volgt Dave Coffin van dcraw hier dus gewoon niet de cr2 conventie. Dat is de werkelijk verklaring denk ik…
De sensorInfo van jouw camera:
MakerNote – SensorInfo: 34 5792 3804 1 1 168 56 5783 3799 0 0 0 0 0 0 0 0
de juiste image dimensions volgen uit:
5792 – left – right = 5792 – 168 – 8 = 5616
3804 – top – bottom = 3804 – 56 – 4 = 3744
waarbij
left = 168
right = 5792 – 1 – 5783 = 8
top = 56
bottom = 3804 – 1 – 3799 = 4
Dat dcraw dit niet gewoon volgt is dus ook niet handig vind ik, want als je vervolgens data wilt calibreren met een programma dat de conventie volgt, terwijl de master calibratie frames al met een programma zijn gemaakt dat dcraw gebruikt, dan heb je niet matchende image dimensions, zoals we al eerder zagen.. ;-(
Dat is zeker goed nieuws! Het blijkt maar weer dat de gebruiker van een programma de zwakste schakel is. Ik kon mij al haast niet voorstellen dat PixInsight tijdens het kalibratieproces bochten afsnijdt. Er zitten heel wat knappe koppen achter dat programma (die elkaar ook scherp houden) en het programma is in de loop der jaren heel wat volwassener geworden. Hou me ten goede: dat betekent uiteraard niet per definitie dat het programma geen fouten bevat.
@mauricetoet, zoiets als flat-calibratie implementeren zou niet teveel problemen moeten opleveren inderdaad. Dus ik vond het zelf ook erg vreemd dat sommige resultaten uit Pixinsight zo significant slechter zijn na de flat-calibratie als je het vergelijkt met wat mijn programma eruit gooit. Ik ben in ieder geval door jouw data wel overtuigd dat de problemen van andere pixinsight gebruikers dus mogelijk elders liggen ;-)Unruhe’s probleem (Jean Paul Durman) op het astroforum is echter nu nog niet opgelost, die krijgt erg slechte flat-calibratie in Pixinsight terwijl hij fits files in pixisnight calibreert. Hij heeft die verkregen met SGP. Nu verdenk ik SGP ervan dat die de CR2 data uit zijn Canon 60D verkeerd omzetten naar FITS na capture. Dus dan krijgt hij mogelijk FITS files met bijvoorbeeld de witbalans camera settings er ingebrand… dat zou dan een verklaring zijn en een waarschuwing mogelijk voor iedereen die SGP gebruikt.
Ik zou adviseren aan iedereen met een DSLR, als je een capture programma gebruikt, probeer je data dan altijd op te slaan zo dicht mogelijk bij de bron, dus als CR2 file in het geval van Canon. Dan loop je het minste risico, dat het capture programma je data om zeep helpt bij conversie naar bijvoorbeeld FITS.
Unruhe’s probleem (Jean Paul Durman) op het astroforum is echter nu nog niet opgelost, die krijgt erg slechte flat-calibratie in Pixinsight terwijl hij fits files in pixisnight calibreert. Hij heeft die verkregen met SGP. Nu verdenk ik SGP ervan dat die de CR2 data uit zijn Canon 60D verkeerd omzetten naar FITS na capture. Dus dan krijgt hij mogelijk FITS files met bijvoorbeeld de witbalans camera settings er ingebrand… dat zou dan een verklaring zijn en een waarschuwing mogelijk voor iedereen die SGP gebruikt.
Dat zou inderdaad een verklaring kunnen zijn. In SGP kun je ook instellen dat de data gewoon in CR2-formaat worden opgeslagen (of beide: CR2 en FITS). Zie hier. Dat is gelijk een goed aanknopingspunt om verdere experimenten uit te voeren.
Overigens ook een interessant draadje op het SGP forum hierover.
- You must be logged in to reply to this topic.