- This topic has 34 replies, 4 voices, and was last updated 7 years, 5 months ago by
.
-
Posts
-
Met zo’n live-test kom ik natuurlijk wel op aanpassingen in mijn workflow terecht. Zo had ik onder INDI een zogenaamde “WatchDog” actief staan. Deze draait, net als de andere device drivers, op de Pi op mijn montering. De WatchDog doet een simpele Ping om de zoveel tijd naar de computer binnen en als er 10min niks vernomen is (crash bijv. binnen) dan parkeert de boel automatisch.
Dit heb ik nu niet meer. Nu zat ik te denken zelf een simpel scriptje te maken om op de Pi te draaien, maar vraag mij dan af of je in ASCOM een parkeer commando kan sturen.. weet iemand dat toevallig?
Niet live getest, maar al wel op gewoon een plaatje, werkt prima. Via Astrometry doe ik dat, offline.
@keesscherer Ah, dat bestaat dus in ieder geval. Eens onderzoeken of dat mogelijk is, dank!
Als plate solven werkt hoef je eigenlijk niet meer uit te lijnen. Gewoon de boel goed op de pool zetten, telescoop ongeveer op home positie zetten (richting poolster) en dan verder via platesolven werken. Ideaal!
Als plate solven werkt hoef je eigenlijk niet meer uit te lijnen. Gewoon de boel goed op de pool zetten, telescoop ongeveer op home positie zetten (richting poolster) en dan verder via platesolven werken. Ideaal!
Nou ideaal…. ideaal is niet uitlijnen en niet platesolven.
Als plate solven werkt hoef je eigenlijk niet meer uit te lijnen. Gewoon de boel goed op de pool zetten, telescoop ongeveer op home positie zetten (richting poolster) en dan verder via platesolven werken. Ideaal!
Nou ideaal…. ideaal is niet uitlijnen en niet platesolven.
…of gewoon de foto van internet downloaden!
Ik las net op het forum aldaar, dat SGP in 16-bit zou werken, ongeacht de bit-rate van de camera. Klopt dat en houdt dit in dat SGP de foto, ook in raw, aanpast? Er was daar een vraag over de ADU count van flats en dit zou dus in SGP altijd op zo’n 30.000 moeten zitten.
Ik las net op het forum aldaar, dat SGP in 16-bit zou werken, ongeacht de bit-rate van de camera. Klopt dat en houdt dit in dat SGP de foto, ook in raw, aanpast?
Dat hoeft niet te kloppen. SGP slaat de Canon ata b.v. op als CR2, dat kan gewoon de 14 bit raw zijn. Maar wanneer SGP die CR2 inleest om er wat mee te gaan doen dan is er kennelijk een vertaling naar 16 bit. De opgeslagen CR2 files zouden dan gewoon 14 bit moeten zijn.
De File explorer van Pixinsight geeft ook al geen uitsluitsel. Zelfs een Canon Raw CR2 direct uit de camera heeft 16 bit per sample, net als de files uit Backyard EOS en SGP.
De bitrate van een camera (dynamic range) staat los van de wijze waarop een programma een file codeert (image encoding bits). De maximale adu count van 14 bit raw is en blijft 16384. Pixinsight gebruikt ook 16 bits. In Pixinsight wordt een een 14 bit raw niet ge-rescaled. De 14 bit nummers bezetten aldus de eerste 14 bits van de 16 bits. In SGP vindt -zo te lezen- wel een re-scaling plaats.
De bitrate van een camera (dynamic range) staat los van de wijze waarop een programma een file codeert (image encoding bits). De maximale adu count van 14 bit raw is en blijft 16384. Pixinsight gebruikt ook 16 bits. In Pixinsight wordt een een 14 bit raw niet ge-rescaled. De 14 bit nummers bezetten aldus de eerste 14 bits van de 16 bits. In SGP vindt -zo te lezen- wel een re-scaling plaats.
De vraag van Vincent was volgens mij of de Canon CR2 die door SGP wordt opgeslagen een 14 of 16 bit format heeft. Dat de rescaling in SGP plaats vindt in de eigen weergave is duidelijk maar ook SGP zou de “pure” Canon raw kunnen opslaan (Camera uitlezing en ongeconverteerde opslag met alleen toevoeging van de filenaam volgens SGP definitie)
De door Vincent gestelde vragen waren mij duidelijk : -) Ik reageerde op het achterliggende aspect m.b.t. de adu count van flats. Voor een 14 bit camera is deze streefwaarde indien je gebruikt maakt van SGP (als gevolg van het rescalen) inderdaad zo’n 30.000 en in PI – waar geen re-scaling plaats vindt zo’n 2.000.
- You must be logged in to reply to this topic.