Subject: unsigned images

From: owen at astro.washington.edu (Russell E. Owen)
Date: Wed, 19 Feb 1997 14:14:19 -0800

Did the FITS committee ever come up with a standard for handling 16-bit
unsigned images correctly?

If not, has any large organization come up with their own private standard?

I have great antipathy to converting all my data as its written, and then
converting it again as it's read out. Like most night-time astronomical
applications, our cameras all produce 16-bit unsigned data. It is a huge
advantage to be able to read and write this data in a single operation
w/out converting it first.

-- Russell

---

From: sla at hires.ucolick.org (Steve Allen)
Date: 20 Feb 1997 11:15:28 GMT

In article <owen-ya023080001902971414190001 at news.u.washington.edu>,
>w/out converting it first.

Only two steps are necessary.

1) flip the high order bit of each pixel
	(if your CCD controller has DSP capability this can be done as
	part of the data pipeline so that you incur no delay)
2) set BZERO in the FITS header.

Then you have standard BITPIX=16 FITS images.
No modification to existing standard is required.
--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 408 459 3046     FAX: +1 408 454 9863
WWW: http://www.ucolick.org/~sla                PGP public keys:  see WWW

---

From: wmo at wansor.jpl.nasa.gov (Bill Owen)
Date: 21 Feb 1997 18:09:43 GMT

In article <owen-ya023080002002971216070001 at news.u.washington.edu>, owen at astro.washington.edu (Russell E. Owen) writes:
> In article <5ehbog$jc1 at darkstar.ucsc.edu>, sla at hires.ucolick.org (Steve
> Allen) wrote:
> 
[snips at various places]
> Saving that, does anyone know an ANSI standard portable method of toggling
> the sign bit on a large array of 16-bit integers? I looked into it a bit
> and am embarrassed to say that I ran into a brick wall.

In ANSI Fortran, no *efficient* way.  Many compilers offer extensions such as
IBSET or MVBITS that will let you access pieces of a 16-bit integer.  VAX
has a bitwise exclusive OR, IEOR, that will do the trick:
      VALUE(I) = IEOR (VALUE(I), -32768)

You can always use addition and subtraction if you really want to keep it
ANSI standard.  This is undoubtedly less efficient, though:

      IF (VALUE(I) .GE. 0) THEN
         VALUE(I) = VALUE(I) - 32768
      ELSE
         VALUE(I) = VALUE(I) + 32768
      END IF

Just make sure the test is written as above so that 0 becomes -32768.

In ANSI C, however, the problem is trivial.  Use the bitwise exclusive OR
operator, and the one statement
      value[i] ^= 0x8000;
will flip the sign bit and leave the rest alone.  (Yes, I realize that one
would probably code it up using a pointer instead of a subscript.)  The bit
pattern 0x8000 -- sign bit on, others off -- is -32768 on two's complement
machines.

No matter how you do it, BZERO should be set to +32768.

-- Bill Owen, wmo at wansor.jpl.nasa.gov

---

From: Michael Olberg <olberg at oso.chalmers.se>
Date: Fri, 21 Feb 1997 09:31:41 +0100

> and am embarrassed to say that I ran into a brick wall.

I think, the following code is ANSI compliant:

int i;
short data[DATALEN];

for (i = 0; i < DATALEN; i++) {
    data[i] ^= (1<<15);
}

Or is it the size of the data array (under DOS perhaps) that you are
having 
problems with?

Regards,

---------------------------------------------------------------------------
Michael Olberg           | e-mail: olberg at oso.chalmers.se
Onsala Space Observatory | tel: +46-31-7725507 (work) +46-300-10778
(home) 
S-43992 Onsala, SWEDEN   | fax: +46-31-7725590
-------------------- This quote left blank intentionally
------------------

---

From: Nicolas Devillard <ndevilla at eso.org>
Date: Fri, 21 Feb 1997 13:00:57 +0100

On Fri, 21 Feb 1997, Michael Olberg wrote:
[...]
> for (i = 0; i < DATALEN; i++) {
[...]

ANSI, but not portable. If on your machine (and compiler) 'int i' means
'short int i', you may well run into trouble when addressing more than 32
kpixels. Furthermore, when declaring 'short data[DATALEN]', nothing
ensures that 'data' contains 16 bit integers, nor should any assumption be
made on the its sign. Portability...

Have a look in C FAQ's about portability and machine endian-ness. You may
well find answers to your problem there, together with simple source codes
for data conversion.

Hope it helps,
--Nicolas
 ____________________________________________________________________
/\                                                                   \
\_| Nicolas Devillard               |    E-mail:  nDevil at eso.org      |
  | European Southern Observatory,  |    http://www.eso.org/~ndevilla |
  | Karl-Schwarzschild-Str. 2,      |    Phone:  +49 89 320-06-340    |
  | D-85748 Garching, Germany       |    Fax  :  +49 89 320-06-358    |
  |   ________________________________________________________________|_
  \_/__________________________________________________________________/

---

From: pausch at electra.saaf.se (Paul Schlyter)
Date: 23 Feb 1997 10:29:05 +0100

In article <5ekod7$17m at netline-fddi.jpl.nasa.gov>,
Bill Owen <wmo at wansor.jpl.nasa.gov> wrote:
 
Article: 1563 of sci.astro.fits
 
>          VALUE(I) = VALUE(I) + 32768
 
This is non-portable, since it assumes integers are stored as
2-complement binary numbers, and ANSI FORTRAN has no such requirements
on integers.  Your code will fail on platforms using 1-complement
or sign-magnitude integer representations - not to mention BCD
representation..... yes, there are FORTRAN implementations using
BCD for integers.

-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf.se     psr at net.ausys.se    paul at inorbit.com
WWW:     http://www.raditex.se/~pausch/    http://spitfire.ausys.se/psr/