A question about astronomy FITS files

In Astronomy they seem to like to use FITS (Flexible Image Transport System) files to save and transport data. As I am building an observatory I would like to use file formats that users would be familiar with...but, I kind of have to confess that this "FITS" thing is a little puzzling...

While including almost any data type is rather simple, I also need to include actual "Image" data; as in either "JPEG, or PNG, even TIFF would be okay...something that might actually encapsulate Image data with either 24 or 32 bit color. And, that is the problem...FITS doesn't seem to encapsulate any kind of Image (picture) data at all...just any sort of typical old school array...nowhere do I see where it may encapsulate an array of "object". Perhaps I'm just being blind, or not seeing it for some reason...

And then of course there is another question; what image format do other programs convert the JPG or PNG to for storage...my software would be kind of useless if it wasn't compliant with other existing packages...like FITS Liberator, etc.

So...does anybody know of any complete documentation? Perhaps an SDK, or some sample code where picture/image data is written/read? And, please; do not reference that crap from NASA...it is woefully incomplete.

And of course; what image format do others support?

I'm just about to invent my own format for internal data communication, and let the user be on his own in respect to the FITS system...

Very cool about building your own observatory wish I had the resources for a project like that. I'm stuck with a 70mm refractor fitted with a homemade computer connection built from a old webcam and some rubber piping.

Its been a few years since I worked at the 1-Meter reflector at the University of Toledo but I don't recall FITS being used at all for actual images. We used them to catalog and study stellar spectra of objects. It also stored other data about the object but I don't think a actual image is contained within a FITS file.

a reply to: tanka418

I don't really understand what you want to do, but have you looked here?

originally posted by: jholt5638
Very cool about building your own observatory wish I had the resources for a project like that. I'm stuck with a 70mm refractor fitted with a homemade computer connection built from a old webcam and some rubber piping.

Its been a few years since I worked at the 1-Meter reflector at the University of Toledo but I don't recall FITS being used at all for actual images. We used them to catalog and study stellar spectra of objects. It also stored other data about the object but I don't think a actual image is contained within a FITS file.

I may be trying to over-complicate the whole thing...though I have seen many FITS files that contain image (JPG, PNG like stuff) data.

In my opinion as a software architect; using FITS files is inefficient, in that, image and other data is easier to deal with as a database record with linked or embedded images. The software is easier...in all respects.

But, still, thee is a lot to say about being compliant with existing tools...

Why don't you want to use the FITS image format? You do realize that the format is a standard convention of most astronomy related software, right? Image stacking programs, photometry software, astrometry software is all designed to use the FITS image format. Sure, some programs will also support other formats (particularly other raw uncompressed high bit depth formats like the raw files produced by DSLR cameras), but all the programs I use support the FITS image format. The data is stored in an uncompressed form, and has relevant (and important) header fields for image exposure, start time, even coordinates of the image in some cases. After astrometrically solving an image it will also contain embedded world coordinate system data which allows users to measure the specific coordinates of each pixel of the image with very high precision. Astronomers use the FITS file format for a reason, it's a very useful standard. Let me put it this way; if your robotic observatory does not deliver images in FITS format, professional astronomers and serious amateur astronomers will generally not want to utilize it.

a reply to: tanka418

The FITS format is a data container for scientific data, including 3 dimensional images, (say with astrometric and graphical image data combined).

FITS also includes an ASCII character (plain text) header so that one can get meta-information about the data without viewing it (which may possibly be misleading if the format of the data is misunderstood). Metadata may include equipment calibration details, spatial direction and location of the image, equipment used, time of capture & etc.

Other image formats are purely for 2 dimensional images and also often are lossy, something that is unwanted when employing scientific data at the limits of resolution.

FITS is not efficient and does not attempt to attain efficiency. It is raw data untouched and commented fully.

It doesn't seek to compress the images for transmittal.

In modern anecdote; a FITS file tells more than 1000 words.

originally posted by: ngchunter
Why don't you want to use the FITS image format? You do realize that the format is a standard convention of most astronomy related software, right? Image stacking programs, photometry software, astrometry software is all designed to use the FITS image format. quote]

Yes...well that's the thing; I do want to use it...its just that I'm not finding an image format of any sort.

You talk about the raw data that comes from a sensor, such as a CCD...FITS does not encapsulate that kind of data. At least not that I've been able to find.

Sure FITS will encapsulate what they are calling "image" data, but, when they talk about an "image" they are referring to a memory image, as opposed to a visual image.

I need to encapsulate 24 bit color data. which is actually a "Struct" consisting of three bytes; Red, Green, and Blue. And while I can "stream" JPEG data into a FITS "ImageHDU" I would still need to know the format of the (visual) image data (i.e. JPG, PNG, etc.).

And of course IF I wished to convert the (visual) image into something that FITS CAN handle; I will need to convert It into 3 double (float) arrays, and save them out individually...and of course to actually display those images they have to be re-assembled.

And, hence my issue...

originally posted by: chr0naut
a reply to: tanka418

The FITS format is a data container for scientific data, including 3 dimensional images, (say with astrometric and graphical image data combined).

Well almost...FITS consider an array to be "image" data...in much the same way as your computer's memory contains an "image" f the data currently being used.

This is NOT the same as a "visual" image with pixels containing 24 o 32 bit data.

FITS also includes an ASCII character (plain text) header so that one can get meta-information about the data without viewing it (which may possibly be misleading if the format of the data is misunderstood). Metadata may include equipment calibration details, spatial direction and location of the image, equipment used, time of capture & etc.

Other image formats are purely for 2 dimensional images and also often are lossy, something that is unwanted when employing scientific data at the limits of resolution.

FITS is not efficient and does not attempt to attain efficiency. It is raw data untouched and commented fully.

It doesn't seek to compress the images for transmittal.

In modern anecdote; a FITS file tells more than 1000 words.

Depends on your definition of a "word"...and in todays world; that may be 64 bits!

No, seriously; I am very familiar with the FITS library from NASA, and find it seriously lacking in a number of critical areas, including documentation. But, still workable with the exception of actually being a "flexible Image transfer system".

You see; when my telescope produces an image it will be up to 10.7 MP worth of 24 bit data, I need to save that "image" as something that can be used in an imaging system, and in a "vision" system...both prefer to use something like a JPG or a PNG which are rather standard visual formats.

I suppose I can always build out the FITS file after the processing is done; but then, there will be no "raw" data available...since FITS can't handle it.

I'm trying to find a better solution, one that meets more than just a few local needs...

originally posted by: tanka418
Sure FITS will encapsulate what they are calling "image" data, but, when they talk about an "image" they are referring to a memory image, as opposed to a visual image.

What on earth are you talking about? It's raw (image) data, the values of each pixel (or even higher dimensional 3d data as mentioned above) are encoded in a raw format.
www.digitalpreservation.gov...

originally posted by: ArMaP
a reply to: tanka418

I don't really understand what you want to do, but have you looked here?

What I'm trying to do...

Encapsulate raw image data from a device like a CCD in a FITS file. The raw data from a CCD is typically a 24 bit data structure that contains 3 - 8 bit unsigned integers.

The FITS system has no provision to store these structs in a native manner.

What it appears I will have to do is build three 2 dimensional arrays to contain the Red, Green, and Blue image data separately. And then trust that any "other party" software saves this data the same way...otherwise it will "look" damn funny.

I anticipate much frustration on this...

originally posted by: ngchunter

originally posted by: tanka418
Sure FITS will encapsulate what they are calling "image" data, but, when they talk about an "image" they are referring to a memory image, as opposed to a visual image.

What on earth are you talking about? It's raw (image) data, the values of each pixel (or even higher dimensional 3d data as mentioned above) are encoded in a raw format.
www.digitalpreservation.gov...

What am I talking about; I'm talking about how that data is represented, or "encoded" in your computer.

Image data from your CCD is a data structure that contains 24 bit color data , unless of course you're using a black and white CCD. In which case it is still 24 bit color data with all three colors containing the same unsigned integer.

Oh, and we are talking about the actual representation of that data inside your computer, not to conceptual representation that you understand. Color in all computers is represented by what is called a "Struct" or data structure. In the case of color image data it is always, in all computers a 32 bit structure containing Alpha, Red, Green, and Blue color data, though frequently the Alpha is simply set to 255, it's highest value, yielding no transparency. It is through this data struct that your computer "draws" a color image on your monitor.

As I've already indicated; I have a solution, I just don't like it...though I will be thanking you for your assistance with this question...And everyone else too...Thank you.

originally posted by: tanka418

originally posted by: ArMaP
a reply to: tanka418

I don't really understand what you want to do, but have you looked here?

What I'm trying to do...

Encapsulate raw image data from a device like a CCD in a FITS file. The raw data from a CCD is typically a 24 bit data structure that contains 3 - 8 bit unsigned integers.

The FITS system has no provision to store these structs in a native manner.

What it appears I will have to do is build three 2 dimensional arrays to contain the Red, Green, and Blue image data separately. And then trust that any "other party" software saves this data the same way...otherwise it will "look" damn funny.

I anticipate much frustration on this...

Although you could use three 2D arrays, that is complicating things unnecessarily.

Why not create a single 2D array with each data record being 24 bits or a 32bit word (with alpha value). You then simply concatenate the 8 bit 'color' integers into a single pixel record. No need to separate the color values as the 8 bit unsigned integer format is implicit. The values can then be separated at the display end with some XORing or some modulo math, i.e: store the picture data pretty much exactly as it comes from the CCD chipset. Frame size and details can stored in the header and/or implicitly in the array dimensions. Easy.

originally posted by: tanka418

originally posted by: ngchunter

originally posted by: tanka418
Sure FITS will encapsulate what they are calling "image" data, but, when they talk about an "image" they are referring to a memory image, as opposed to a visual image.

What on earth are you talking about? It's raw (image) data, the values of each pixel (or even higher dimensional 3d data as mentioned above) are encoded in a raw format.
www.digitalpreservation.gov...

What am I talking about; I'm talking about how that data is represented, or "encoded" in your computer.

Image data from your CCD is a data structure that contains 24 bit color data , unless of course you're using a black and white CCD. In which case it is still 24 bit color data with all three colors containing the same unsigned integer.

Actually my CCD encodes 16 bit data on each channel. Some CCD's even encode 32 bit data, particularly high quality monochrome astronomical CCDs. The intensity value and position of each pixel is encoded in the FITS format. Each pixel value on each channel is encoded in 16 bits in my case, so the maximum value is much higher than 255, allowing for much higher bit depth images.

originally posted by: chr0naut
Although you could use three 2D arrays, that is complicating things unnecessarily.

Why not create a single 2D array with each data record being 24 bits or a 32bit word (with alpha value).

Mainly because GDI+, the Microsoft library responsible for putting images on your screen, takes the struct I've mentioned. This struct contains 24 bits of data, but it is formatted as three 8 bit integers, and all of the library routines (methods) depend on this "struct". The only option I would have is to try to treat the value as a 24 bit binary...

And while this might work, I don't know IF it is how others do it...I'm still searching for that data.

You then simply concatenate the 8 bit 'color' integers into a single pixel record. No need to separate the color values as the 8 bit unsigned integer format is implicit. The values can then be separated at the display end with some XORing or some modulo math, i.e: store the picture data pretty much exactly as it comes from the CCD chipset. Frame size and details can stored in the header and/or implicitly in the array dimensions. Easy.

How does One concatenate an integer?

I take it you've read the official Definition of the Flexible Image Transport System?

fits.gsfc.nasa.gov...

originally posted by: nataylor
I take it you've read the official Definition of the Flexible Image Transport System?

fits.gsfc.nasa.gov...

Yes...several times...

originally posted by: tanka418

originally posted by: chr0naut
Although you could use three 2D arrays, that is complicating things unnecessarily.

Why not create a single 2D array with each data record being 24 bits or a 32bit word (with alpha value).

Mainly because GDI+, the Microsoft library responsible for putting images on your screen, takes the struct I've mentioned. This struct contains 24 bits of data, but it is formatted as three 8 bit integers, and all of the library routines (methods) depend on this "struct". The only option I would have is to try to treat the value as a 24 bit binary...

And while this might work, I don't know IF it is how others do it...I'm still searching for that data.

You then simply concatenate the 8 bit 'color' integers into a single pixel record. No need to separate the color values as the 8 bit unsigned integer format is implicit. The values can then be separated at the display end with some XORing or some modulo math, i.e: store the picture data pretty much exactly as it comes from the CCD chipset. Frame size and details can stored in the header and/or implicitly in the array dimensions. Easy.

How does One concatenate an integer?

The GDI+ struct can be created on the fly, in RAM, as temporary arrays at display time.

The file content need not be in the final image display format but can more accurately represent a data stream, direct from the instrument, ported straight into an array.

By concatenate, I was merely implying that several integer bytes are stuck together, end to end, into either a 24 or 32 bit 'word', with no intervening separator value.

Like bricks of data in a row. As each brick is a known size (a byte), you don't have to put any type of separator there.

The data can be decoded simply by reading each record a byte at a time.

As each word is a known size (three or four bytes) you again don't have to define separators and such. If the array dimensions match the pixel numbers across and down, respectively (or even on an additional 'Z' axis if included), you don't need to even define the array dimensions elsewhere as the screen display size is defined by the sizes of the array dimensions and the lines and rows are also implicit.

Implicit structure, maximizing efficiency.

I'm probably not using the correct terminology (I'm a bit "old school") but I hope you understand.

a reply to: chr0naut

Actually the GDI+ Color struct can't be used. However, it appears that I had not looked deep enough into the BitMap class.

The Bitmap class allow for the manipulation of 64bit color data via the method "lockbit(...)" LockBit allows me to specify the "color depth" and can have any "byte" value from 1 to 64...one of the things I was looking for, but, had to search for because it's not used so much in Internet/server code...

In any case this solves most of this issue.

Thanks for your patience and assistance...