heeft iemand verstand van het .fits format?

WimApon

Pluto
Ik probeer het fits format van een huble foto te lezen.
De file is : 656nmos.fits ergens van het internet gehaald.
Het lukt me niet om er een plaatje van te maken.
Van andere fits files lukt dat me wel.
Ik programmeer het in pureBasic.
Ik kom in de header de volgende keywords tegen: ( er staan er wel 100 in...)

Bitpix = -32
Naxis = 2
Naxis1 = 1600
Naxis2 = 1600
Bscale = 1

het plaatje is dus 1600 bij 1600 pixels over 2 assen ( x en y dus). dat is geen probleem
Bscale = 1 dus er wordt niet gerekend met de waarden van de pixels.

Maar bitpix = -32
als ik de documentatie nalees zou dat betekenen dat een pixel data punt uit een floating point getal van 32 bits bestaat.
Maar als ik dat zo inlees krijg ik geen fatsoenlijk plaatje.
Dit waarschijnlijk omdat mijn programma 3 RGB kleur waardes nodig heeft.
normaal geef ik ze alle 3 de waarde van de groene waarde.
dat werkt altijd goed. ( die waardes liggen tussen 0 en 255)

In dit geval krijg ik wel de vorm van het plaatje maar de pixels schijnen random gevormd te worden.

kan iemand me misschien helpen..... Wat is er mis met die -32

Het programma ASTAP maakt er een prachtig zwart wit plaatje van. Dus ik doe iets fout.

Vast bedankt Wim Apon
 
Laatst bewerkt:

wvreeven

Moderator
Als je programma 3 RGB waardes nodig heeft dan zit daar de fout. Dit is blijkbaar een zwart wit plaatje met maar één kanaal ipv drie.
 
Het is inderdaad een zwartwit plaatje.
NAXIS = 2 betekent: monochroom.
Als het een kleurenfoto was, zou er moeten staan NAXIS = 3.
Er is niks mis met Bitpix = -32.

Het bestand is ook te openen met AstroImageJ:
Hubble testfoto.png
 
Laatst bewerkt:

WimApon

Pluto
Dit vind ik op het internet

KEYWORD: NAXIS
REFERENCE: FITS Standard
STATUS: mandatory
HDU: any
VALUE: integer
RANGE: [0:999]
COMMENT: number of axes
DEFINITION: The value field shall contain a non-negative integer no
greater than 999, representing the number of axes in the associated
data array. A value of zero signifies that no data follow the header in
the HDU. In the context of FITS 'TABLE' or 'BINTABLE' extensions, the
value of NAXIS is always 2.

KEYWORD: NAXISn
REFERENCE: FITS Standard
STATUS: mandatory
HDU: any
VALUE: integer
RANGE: [0:]
COMMENT: size of the axis
DEFINITION: The value field of this indexed keyword shall contain a
non-negative integer, representing the number of elements along axis n
of a data array. The NAXISn must be present for all values n =
1,...,NAXIS, and for no other values of n. A value of zero for any of
the NAXISn signifies that no data follow the header in the HDU. If
NAXIS is equal to 0, there should not be any NAXISn keywords.


Ik vind het erg moeilijk, maar ik lees dit alsof het plaatje 2 assen heeft..... dus horizontaal en verticaal
naxis1 is dan het aantal pixels horizontaal en naxis2 is dan het aantal pixels verticaal....


Maar los van dit; wat is nu die Bitpix = -32

Mijn probleem is dat ik niet begrijp hoe ik de echte data van de file moet inlezen.
4 losse bytes = 32 bits 1 voor rood , 1 voor groen, 1 voor blauw en eentje voor niks. ( zo werkt een .bmp file)
of 2 bytes van 16 bits, of een floating point variabele van 32 bits...
of weet ik veel.....

Als ik dit goed inlees zal ik hetzelfde plaatje krijgen.. \
Mijn vraag is dus kort samengevat... hoe ziet de data voor 1 pixel er uit in deze file...en hoe staat dat in de header omschreven?


dus ?????????


En Wvreeven, als ik voor de 3 rgb waardes dezelfde waarde invul krijg ik een zwart/wit plaatje.
(ik moet het doen met de commando's die mijn purebasic compiler toestaat....)
 
Laatst bewerkt:

Rudy

Donateur
Beschrijving van de standaard is hier te lezen, over BITPIX = -32:

"5.3. IEEE-754 floating point Transmission of 32- and 64-bit floating-point data within the FITS format shall use the ANSI/IEEE-754 standard (IEEE
1985). BITPIX = -32 and BITPIX = -64 signify 32- and 64-bit IEEE floating-point numbers, respectively; the absolute value of BITPIX is used for computing the sizes of data structures. The full IEEE set of number forms is allowed for FITS interchange, including all special values."



Dus 32 bit floating point data, blijkbaar.
 

wvreeven

Moderator
Mijn probleem is dat ik niet begrijp hoe ik de echte data van de file moet inlezen.
4 losse bytes = 32 bits 1 voor rood , 1 voor groen, 1 voor blauw en eentje voor niks. ( zo werkt een .bmp file)
of 2 bytes van 16 bits, of een floating point variabele van 32 bits...
of weet ik veel.....
De beschrijving van het plaatje bevat dit "through a narrow-band 656nm filter (H-alpha)" hetgeen betekent dat het een monochrome opname is. Dus, zoals ik al schreef, je zult je programma moeten aanpassen om monochrome opnames te kunnen openen. De betekenins van de waarde -32 staat hier uitgelegd:

 
  • Leuk
Waarderingen: Rudy

Eelco

Aarde (meestal)
Als je vooral een mooi kleurenplaatje wilt maken heb je nog twee 'banden' nodig, oftewel nog twee monochrome opnames (zoals Hubble ze maakt - het is geen kleurencamera :) ) in andere golflengtes.

Zoek ook 673nmos.fits en 502nmos.fits (ook met NICMOS gemaakt), en combineer die met het FITS bestandje wat je al hebt, zoals bijvoorbeeld hier beschreven:
 

WimApon

Pluto
Heren, dankjewel.
Ik geloof dat ik nu verder kan.
Nog dit: ik ben niet geinteresseerd in het plaatje; Ik wil alleen weten hoe ik dit soort plaatjes met mijn eigen software kan bekijken. en dat wordt nog een hele klus, want ik moet een floating point omvormen tot een integer tussen 0 en 255..
maar ik ga door...

mijn doel is om vol automatisch dingen te kunnen bekijken in de plaatjes die ik met mijn telescoop maak.
Ik moet nog kiezen of ik .fits of .bmp ga gebruiken. daarom deze oefening.
fits kan veel maar je moet met van alles en nog wat rekening houden. bmp daarentegen is simpel en altijd
hetzelfde. Helaas wordt fits altijd in de astronomie wereld gebruikt... dus het is een dillemma.
 

Eelco

Aarde (meestal)
Helaas wordt fits altijd in de astronomie wereld gebruikt... dus het is een dillemma.

Daar is natuurlijk een goede reden voor .... de meeste opnames zijn monochroom, of juist "heel veel multichroom" (spectrale kubussen en zo: naxis3 is dan veel groter dan 3). Ook in de astronomie wereld is FITS nog steeds een 'noodzakelijk kwaad' - we moeten het ermee doen.

Voor snel even een FITS bestandje bekijken kun je natuurlijk ds9 gebruiken (doe ik vaak): https://sites.google.com/cfa.harvard.edu/saoimageds9
Je kunt daarmee ook converteren naar andere formaten - je hoeft het wiel niet opnieuw uit te vinden, toch?

Als ik zelf met FITS bestanden moet rommelen gebruik ik meestal IDL, met de benodigde FITS libraries.
FITS is echt geen leuk formaat om zelf te programmeren ...
 
Laatst bewerkt:

Eelco

Aarde (meestal)
mijn doel is om vol automatisch dingen te kunnen bekijken in de plaatjes die ik met mijn telescoop maak.

Gebruik ds9 in 'command line mode'. Klaar!

ds9 bestaat al een jaar of 30 (heette eerst SAOimage), niet veel jonger dan FITS zelf ...
 

InFINNity Deck

Observatory
FITS plaatjes lezen is inderdaad geen gein. Ik heb zelf ooit in Java een eenvoudig FITS-uitleesprogramma geschreven om wat statistiek met mijn data te doen. Hier al een klein voorproefje waar je mee te maken krijgt, want de data kan in verschillende typen opgeslagen zijn:

Code:
        byte[][] imageB = null;
        float[][] imageF = null;
        short[][] imageS = null;
        double[][] imageD = null;
...
                ImageHDU hdu = (ImageHDU) f.getHDU(0);
                String dataType = hdu.getKernel().getClass().getName();
//                System.out.println(dataType);
                switch (dataType)
                {
                    case "[[B":
                        imageB = (byte[][]) hdu.getKernel();
                        imgWidth = imageB[0].length;
                        imgHeight = imageB.length;
                        mode = 0;
                    break;
                    case "[[F":
                        imageF = (float[][]) hdu.getKernel();
                        imgWidth = imageF[0].length;
                        imgHeight = imageF.length;
                        mode = 1;
                    break;
                    case "[[D":
                        imageD = (double[][]) hdu.getKernel();
                        imgWidth = imageD[0].length;
                        imgHeight = imageD.length;
                        mode = 2;
                    break;
                    case "[[S":
                        imageS = (short[][]) hdu.getKernel();
                        imgWidth = imageS[0].length;
                        imgHeight = imageS.length;
                        mode = 3;
                    break;
                }


Je moet dus eerst testen wat voor datatype de FITS bevat, voordat je de array kan dimensioneren. Je ziet dat ik dus afhankelijk van wat de Kernel retourneert ik een byte[][], float[][], double[][] of short[][] array aanmaak. Wellicht dat er eenvoudiger manieren zijn om dit op te lossen, maar daar ben ik nog niet achter gekomen. ;-)

Nicolàs
 

WimApon

Pluto
bedankt heren,
maar antwoorden geven altijd meer vragen....

Kun je bijvoorbeeld met IDL of DS9 in een plaatje 2 sterren aanwijzen en dan het verschil in helderheid krijgen
( zo'n programma heb ik inmiddels al voor .bmp files gemaakt)
Of kun je van 2 plaatjes de verschillen vinden..... positie of helderheid van alle sterren?

en inderdaad, het wiel opnieuw uitvinden is niet echt nodig, maar ik vind het wel leuk


Voor mij is het voordeel van .fits files dat je heel veel vrije tekst in de header kunt schrijven.
 
Laatst bewerkt:
mijn doel is om vol automatisch dingen te kunnen bekijken in de plaatjes die ik met mijn telescoop maak.
Ik moet nog kiezen of ik .fits of .bmp ga gebruiken. daarom deze oefening.
Kun je bijvoorbeeld met IDL of DS9 in een plaatje 2 sterren aanwijzen en dan het verschil in helderheid krijgen
( zo'n programma heb ik inmiddels al voor .bmp files gemaakt)
Of kun je van 2 plaatjes de verschillen vinden..... positie of helderheid van alle sterren?
In een ander topic schreef je dat je een eVscope hebt.
Ik las vandaag in de gebruikersgroep van AIP4Win dat iemand FITS files uit een Unistellar eVscope haalt, die bestanden in AIP4Win laadt en dan precies doet wat jij wilt.
Als het met AIP4WIN lukt, dan moet het ook met andere fotometriesoftware en/of blinksoftware lukken.
Waarom zou je dan nog .bmp files gebruiken of zelf zwoegen om een programma te schrijven?
 

WimApon

Pluto
Heee Fabricius, dat ziet er goed uit. Ik ga daar ook eens kijken en het programma bekijken.
natuurlijk als het allemaal al mogelijk is , dan ga ik niet zwoegen.
Maar uit de eVscope komen .png files... maar die zijn om te zetten naar .fits.

goeie tip .. ik ga aan de slag
 

Eelco

Aarde (meestal)
Kun je bijvoorbeeld met IDL of DS9 in een plaatje 2 sterren aanwijzen en dan het verschil in helderheid krijgen
( zo'n programma heb ik inmiddels al voor .bmp files gemaakt)
Je zou met ds9 de FITS files naar BMP files kunnen omzetten, en dan je eigen programma verder gebruiken ...
 

WimApon

Pluto
Fabricius, ik heb aip4win inmiddels op mijn pc gezet.... tjonge dat gaat wat tijd kosten voor ik er iets van snap.. hi hi
maar ik ga het proberen.
 

WimApon

Pluto
Ik geloof dat Aip4win wat tegenvalt: blink kan alleen met CCD files.
En het meten van de relatieve lichsterkte van een ster, ziet er mooi uit, maar de verhouding tussen 2 sterren , zo gemeten, geeft
heel andere waarden dan mijn eigen programmatuur. mijn prog een factor 3 en aip4win geeft een factor 25.
roteren en verschuiven van plaatjes gaat wel heel soepel, maar omdat blink dan niet werkt heb ik er niets aan...
Maar ik puzzel nog even door.
 
Ik geloof dat Aip4win wat tegenvalt: blink kan alleen met CCD files.
Met AIP4WIN kan ik de bestandsformaten gebruiken die gangbaar zijn in de astrowereld. Heb het nog even getest. Het blinken lukt in ieder geval met RAW files direct uit de DSLR en FITS files.
Overigens vind ik de blinkfunctie van Astroart prettiger in het gebruik (werkt ook met FITS).

Wat bedoel je met "factor 3"? Helderheidsverschillen tussen sterren worden gemeten in magnituden (of in fluxes, door mensen die te lui zijn om fluxverschillen in magnituden om te rekenen). Om helderheidsverschillen te meten, moeten bepaalde stappen worden gevolgd. Dit is geen sinecure: juiste meetcirkel kiezen die past bij de te meten objecten, niet te groot en niet te klein, hemelachtergrond zonder storende andere sterren selecteren etc.
Zo dus:
Fotometrievoorbeeld M67 AstroArt.jpg
Werkt je eigen programmatuur op dezelfde manier?

Meer leesvoer:

Korte introductie in fotometrie

Uitgebreide handleiding fotometrie
 

WimApon

Pluto
Hoi Fabricius, nou het lukt me alleen maar om .fits files in te lezen als ik "open file" doe uit het hoofdmenu.
Ik krijg andere formatten dan niet eens te zien.
En als ik toch probeer te blinken met 2 fits files, krijg ik de melding dat het alleen voor CCD files werkt....??
Wat doe ik verkeerd dus? want blinken is wat ik heel graag wil.. eerst wat roteren en verschuiven.. en dat
werkt prima met aip4win.



De helderheids verschillen doe ik waarschijnlijk ongeveer net zo als aip4win. Ik kies een gebiedje waarin alleen
de te onderzoeken ster zit. de groote van het gebiedje bepaal ik zelf. Als ik 2 sterren vergelijk neem ik natuurlijk
in beide gevallen het zelfde gebiedje. Ik tel dan de groen waarde van alle pixels op en deel die door het totaal
aantal pixels ( is niet echt nodig...) dan doe ik hetzelfde voor de andere ster. De twee gevonden waarden deel
ik dan op elkaar en krijg dan een soort helderheids verschil tussen de beide sterren.
Ik trek de achtergrond helderheid er niet van af, maar dat is eenvoudig te doen.
Als ik het een heleboel keer herhaal, krijg ik steeds ongeveer dezelfde waarde.
IK doe dus niet aan flux of magnetudes... Ik wil alleen weten of er uberhaupt een meetbaar helderheidsverschil is.
( ik weet dat het een vieze methode is, maar voor even vind ik het goed genoeg.)
Ik wil deze methode om een aantal dagen ( of uur) herhalen en dan zien of dit helderheids verschil
verandert. Ik ben me bewust dat het waarschijnlijk veel ingewikkelder is... maar.. ik zie wel
( Als 1 van beide sterren verandert moet het helderheidsverschil tussen de zelfde sterren ook veranderen)
(ik meet dus op deze manier de waarde van de individuele pixels samen met de groote van het vlekje op de foto)

Het is waarschijnlijk een heel amateuristische benadering.. maar ach.. ik vind het leuk zo.
 
Laatst bewerkt:
Bovenaan Onderaan