[fitsbits] Question(s) regarding development of proprietary FITS manipulation software. . .

[Maren Purves]

you use cfitsio (well, I use cfitsio because I primarily
program in C these days when I have a chance, but I do a
few other things than write FITS files), and read in the header
which then tells you what length your data are ...

Again, the data have nothing to do with RGB pixels,
they are in physically meaningful units (and if it isn't
specified what they are you have pretty unreduceable (sp?)
data). You can map them to a color scale, but that's up
to you.

Maren 
(trying to design and implement a cryostat control
system that needs to be converted from VAX FORTRAN
to EPICS, probably on vxWorks, but could end up being
Linux - on the side to dealing with operational issues)

On Tue, 18 Sep 2007, gberz3 wrote:

> The silence is deafening. . .
>
> Alright all.  I suppose I was asking the right question(s) in the
> wrong manner in the beginning.  I have now actually figured out how to
> interpret 2-D image data.  The information literally has to be read in
> 8-byte increments and converted to a double.  That will then allow me
> to map RGB pixel data to a buffer.
>
> *THAT* is what I needed to know.  How to read in and interpret the
> data.  I had *NO* idea what that "garbage" was supposed to mean or how
> many chickens I needed to sacrifice in order to get it to work.
>
> Anyway, thanks to all that contributed.  My apologies for any
> confusion.
>
> Regards,
> Michael
>
> On Aug 27, 10:38 am, Michael Williams <gbe... at gmail.com> wrote:
>> Ok, I actually asked a follow-on question in another post/e-mail.
>> Basically I asked if these astronomers images were literally live
>> images (perhaps of the stars, or nieces and nephews), or if they were
>> simply arbitrary graphical representations of data that had no
>> reference in reality.  Also, given the fact that, as you said,
>> reverse transformation isn't always possible, why in the world does
>> it matter if the user can perform image manipulations of any type?  I
>> mean, if there is no consistent way to produce an image, then why do
>> we care?
>>
>> Thanks,
>> Michael
>>
>> On Aug 27, 2007, at 5:15 AM, Thierry Forveille wrote:
>>
>>> gberz3 a écrit :
>>>> Why would *anyone* present FITS data as images if they are
>>>> not image data?  Why not represent it as sound?
>>>> I guess that's what I'm getting at.  What relevance does an image
>>>> have
>>>> to actual FITS data if there is no "attached" image, and what is the
>>>> proper means by which to display said image?
>>> The issue is mostly your notion of an image, vs an astronomer's
>>> notion of the same. To you an image is something that can be
>>> univocally displayed on a screen or printed, while to
>>> astronomers it is a set of values (ideally in physical units,
>>> such as Watts per square meter per steradian) sampled on a
>>> regular grid. There is some link between the two notions,
>>> but not a unique one: an astronomer's image can be displayed
>>> but not in one unique way, and the reverse transformation
>>> if/when at all possible, requires additional information
>>> (e.g. the physical values for a subset of the pixels) and
>>> significant calibration work. Essentially, an astromer's
>>> image is a richer dataset, and someone needs to decide how
>>> to degrade that information to what a display can show.
>>
>>> In addition, images (in the astronomer's definition) is only
>>> one of the data classes that can be stored in FITS.
>
>
>