problemer med jupiter og nyt kamera

[jesperDeltager Neutron star]

Vedrørende histogrammet så fungerede det også for mig efter hensigten da jeg tog Saturn forleden morgen. Jeg ved ikke hvorfor det så anderledes ud første gang.

Her er et par forslag:

1. Jeg synes også indstillingerne bør gemmes ved programafslutning.

2. ROI, ekempelvis på 400 x400 ville muliggøre højere framerates. Kameraet er så følsomt at man kan komme ud for at 30 eller 52 fps betyder “spildtid” mellem eksponeringerne.

3. En god eksponeringskontrol, med average og peak søjler, ala Lucam Recorder.

4. Mulighded for at fastsætte et antal sekunder en optagelse skal vare, fremfor et antal frames. Tiden giver mere mening i planetfoto, end antallet af frames.

5. Mulighed for at give filerne et selvvalgt navn.

Jeg skal nok komme med mere senere. Der er nogle gode features i programmet, bla. den nederste linje, hvor man får at vide hvor mange frames der kommer fra kameraet og hvor mange der skrives til disken. Også ideen med at lade framerate og eksponeringstid styres af samme slider, som bliver rød hvis tiden bliver så lang at frameraten falder, er god.

[motomandk Main Sequence]

Hej Jesper
kan du maile et screenshot af hvordan de average&peak søjler ser ud og ganske kort beskrive hvad de udtrykker?

Ønsker du at opnå højere frame-rate ved ROI? Set i lyset () af at udlæsningshastigheden fra chippen er konstant, men at tiden derved bliver kortere?

/Henrik (H)

[jesperDeltager Neutron star]

Hej Henrik,

Herunder er et sceenshot fra Lucam recorder. Søjlerne opdateres live, og fungerer sådan at mean søjlen viser et gennemsnit af billedets eksponering. Peaksøjlen viser de lyseste pixels. Jeg tror det må være for nogle få nabopixels sammen, og ikke bare en pixel, for at undgå at hotpixels vises på søjlen. På billedet her er de to søjler ret ens fordi kameraet bare lå uden optik. Peak søjlen giver mulighed for at styre eksponeringstiden til lige inder mætningspunktet for den lyseste del af motivet.

ROI plejer at virke sådan at kun det valgte udsnit pixels læses ud, og man får derfor en kortere udlæsningstid selv om udlasningshastidgheden er den samme. Man kan derfor opnå en højere framerate. Hvis hele billedet læses ud selv om det kun er udsnittet der gemmes hjælper det derimod ikke på frameraten, så den metode dur ikke.

[motomandk Main Sequence]

Jesper wrote: Vedrørende histogrammet så fungerede det også for mig efter hensigten da jeg tog Saturn forleden morgen. Jeg ved ikke hvorfor det så anderledes ud første gang.

Her er et par forslag:

1. Jeg synes også indstillingerne bør gemmes ved programafslutning.

2. ROI, ekempelvis på 400 x400 ville muliggøre højere framerates. Kameraet er så følsomt at man kan komme ud for at 30 eller 52 fps betyder “spildtid” mellem eksponeringerne.

3. En god eksponeringskontrol, med average og peak søjler, ala Lucam Recorder.

4. Mulighded for at fastsætte et antal sekunder en optagelse skal vare, fremfor et antal frames. Tiden giver mere mening i planetfoto, end antallet af frames.

5. Mulighed for at give filerne et selvvalgt navn.

Jeg skal nok komme med mere senere. Der er nogle gode features i programmet, bla. den nederste linje, hvor man får at vide hvor mange frames der kommer fra kameraet og hvor mange der skrives til disken. Også ideen med at lade framerate og eksponeringstid styres af samme slider, som bliver rød hvis tiden bliver så lang at frameraten falder, er god.

Jeg har et par svar:

1. Har givet ham(Qiu) et par ekstra oplysninger han bad om – han vender tilbage.

2. Qiu melder at han umiddelbart vil kunne lave nogle faste ROI som f.eks. 200×200, 300×300 og 400×400. At lave variabel ROI kræver lidt ‘ommøblering’ af skærmbilledet og driveren. Vil det løse opgaven på kort sigt? Jeg har bedt ham bekræfte, at det vil give højere frame-rate (dvs. rigtig ROI og ikke et software udpluk af det fulde billede).

3.+4. mener han er rimelig nemt at lave.

5. Der er allerede en mulighed for at give eget filnavn – se på dette billede under ‘suffix’ (jeg ville kalde det prefix …..):

Yderligere svar:

Bit dybde kontra filformat:
14bit kan p.t. udelukkende gemmes i .fit format, dvs. i RAW
8bit kan gemmes i .jpg, .avi, .fit og .bmp

Histogram der ‘fryser’:
Histogrammet sættes ud af drift under optagelser i 14bit og ved ‘high priority disk write’ for at spare CPU tid. Qiu skriver at mange anvender ATOM baserede notebook til deres opstillinger og den er ikke hurtig nok hvis histogrammet skal opdateres.

Jeg vender tilbage med yderligere svar når de foreligger.

Hilsen
Henrik (H)

motomanDK2011-01-14 20:53:21

[jnielsen Planet]

Hmmm. lyder noget “ambitiøst” med Atom processor og så de krav som høj framerate osv. til astro camera optagelser stiller.

En strøtanke kunne være, at man “spurgte på” hvilken processor der sidder i og så slå funktionalitet til/fra derefter. En Intel i5 / i7 burde sagten kunne trække det hele.

[jnielsen Planet]

En anden ide kunne være, at udnytte mulighederne der ligger i flere kerner på alm. cpu’er idag. Min i5 har f.eks. 4 kerner.

Hvis man har problemer med at få skrevet hurtigt nok ned til disken, kunne man have en separat thread håndtere dette. Dette kunne gøres ved at lade den thread der samler data fra cameret gemme data i memory og så have en separat thread gemme på disc.

Kommer den sidstnævnte bagud vil memory forbruget stige indtil optagelserne er færdige. Kræver selvfølgelig noget RAM men den udskrivning er nok lille i forhold til resten af udstyret og 64-bit er jo også mere eller mindre standard (dvs. “no-limits i praksis på RAM allokering forudsat hardwaren kan klare det ).

[jesperDeltager Neutron star]

motomanDK wrote: Jeg har et par svar:

1. Har givet ham(Qiu) et par ekstra oplysninger han bad om – han vender tilbage.

2. Qiu melder at han umiddelbart vil kunne lave nogle faste ROI som f.eks. 200×200, 300×300 og 400×400. At lave variabel ROI kræver lidt ‘ommøblering’ af skærmbilledet og driveren. Vil det løse opgaven på kort sigt? Jeg har bedt ham bekræfte, at det vil give højere frame-rate (dvs. rigtig ROI og ikke et software udpluk af det fulde billede).

3.+4. mener han er rimelig nemt at lave.

5. Der er allerede en mulighed for at give eget filnavn – se på dette billede under ‘suffix’ (jeg ville kalde det prefix …..):

2. Faste ROI er meget fint. Det er ikke nødvendigt med selvvalgte udsnit.

3.+4. Cool!

5. Ja jeg har opdaget det i mellemtiden . Alzhimer light.

[lasDeltager Nova]

Vi vil også gerne have en knap der gør at vi kan filme igennem skyer….

Nå ikke, men jeg syntes at det lyder godt at programmet nu udvikles yderligere. Jeg syntes personligt at punkt 1. er vigtigt.

Hvad gør mit kamera egentlig når jeg kører i den lave opløsning? Hiver det hele billedet ned men viser kun et udsnit eller ?

[motomandk Main Sequence]

Jeg sidder og snakker med Qiu på Messenger – han fortæller at mindre horisontal udsnit IKKE giver højere FPS. Så han foreslår 500*300 som fast lavere ROI – hvad siger i til det?
/Henrik (H)

[motomandk Main Sequence]

Han har netop sagt, at han vil starte på det i morgen! Jeg skal nok holde ham til ilden.
Han vil lave:
1. 500×300 fast ROI
2. Average/peak meter
3. Mappe og billed format gemmes

en helt anden ting – Qiu fortæller at om ganske kort tid kan man få IMG0H med ICX618 i farve. Lyder det som en god idé?

/Henrik (H)

motomanDK2011-01-15 11:03:11

[jesperDeltager Neutron star]

500×300 er helt fint, men 300 på den ene led er nok også tæt på at være det mindste der er brugbart i praksis. Mindre vil give problemer med opløsning og tracking.

[jesperDeltager Neutron star]

motomanDK wrote: Han har netop sagt, at han vil starte på det i morgen!  Jeg skal nok holde ham til ilden.Han vil lave:1. 500×300 fast ROI2. Average/peak meter3. Mappe og billed format gemmes/Henrik (H)

Det lyder sgi godt Henrik

[lasDeltager Nova]

500×300, vil det også være brugbart på IMG0s? Og igen, hvad gør kameraet når jeg kører i den lave opløsning nu?

Vil han ikke kunne lave det så ens preferencer i programmet gemmes? Der er jo stadig nogle parametre at sætte ved program genstart.

[mogensDeltager Super Nova]

LucamRecorder har et ekstra Histogram plus kontrol af filterhjul, hvilket er en stor fordel ved hurtigt filterskift med mit TruTek-filterhjul.-I det hele taget et fremragende program som jeg bruger til SkyNyx og DBK med Ala-chip.-Håber han snart tilføjer Flea3!

Billedet er af en såkaldt bjælkegalakse

[motomandk Main Sequence]

Det ser godt ud Mogens! Hvordan interface’er programmet til kameraerne? Skal producenten af dette program skrive speciel kode (programmere) for at anvende andre kameratyper?
/Henrik (H)

[Forfatter]

Indlæg