Registax 32 bit FIT files- why don't they work in other programs?

"Blaine Sanford" wrote in message
ink.net...
I downloaded the demo of MaximDL today, which is fully functional for 30
days. I opened one of the 32 bit Reg. FITS and the same problems. When
I
look at the historgram in Maxim, it looks like only part of the file is
there with the other part missing... my guess is that Maxim is reading
only
in 16 bits, so the other 16 bits is being cut off. No amount of
historgram
manipulation will make the image appear normal .

Blaine
Have a look at the header information (view, 'fits header window'). What
does the 'bitpix' field show?. Maxim DL4, definately can read and write
32bit FITs files, and can even read (though not write), 64bit ones. If the
bitpix field does show that the file has been recognised as a 32bit type,
it'd be a bit more 'data', as to what is going on.

One possibility that leaps to mind, is that the 32bit format standard, is
for a signed number. If Registax, was using the 32nd bit as data, rather
than a sign, it'd require adding a constant offset of 2147483648 to the
image, to make this work (the same bodge has to be applied to Maxim's own
16bit FITs files, using 32768). Maxim stores this offset value into the
FITs header, in the 'BZERO' field, to show that the zero poin is offset by
this amount. if Registax is using the numbers this way, but not storing
this offset, Maxim would not perform the offsetting for you.
The result would not be trimmed of at 16bits, but in image terms, would
look just as odd!...

Best Wishes

Roger,

Here is what I get when I open a Registax 32 bit FIT in MaximDL:

SIMPLE = T
BITPIX = 32
NAXIS = 2
NAXIS1 = 640
NAXIS2 = 480
BSCALE = 1
BZERO = 32768
DATE-OBS = '30/12/99'
TIME-OBS = '12:36:17'
OBJECT = ''
INSTRUME = ''
EXPOSURE = ''
OBSERVER = ''
COMMENT = REGISTAX V2.0
COMMENT =

How do I add the offset you speak of? I tried adding it in another program,
but it didn't seem to have any effect.

Blaine



"Roger Hamlett" wrote in message
...

"Blaine Sanford" wrote in message
ink.net...
I downloaded the demo of MaximDL today, which is fully functional for 30
days. I opened one of the 32 bit Reg. FITS and the same problems. When
I
look at the historgram in Maxim, it looks like only part of the file is
there with the other part missing... my guess is that Maxim is reading
only
in 16 bits, so the other 16 bits is being cut off. No amount of
historgram
manipulation will make the image appear normal .

Blaine
Have a look at the header information (view, 'fits header window'). What
does the 'bitpix' field show?. Maxim DL4, definately can read and write
32bit FITs files, and can even read (though not write), 64bit ones. If the
bitpix field does show that the file has been recognised as a 32bit type,
it'd be a bit more 'data', as to what is going on.

One possibility that leaps to mind, is that the 32bit format standard, is
for a signed number. If Registax, was using the 32nd bit as data, rather
than a sign, it'd require adding a constant offset of 2147483648 to the
image, to make this work (the same bodge has to be applied to Maxim's own
16bit FITs files, using 32768). Maxim stores this offset value into the
FITs header, in the 'BZERO' field, to show that the zero poin is offset by
this amount. if Registax is using the numbers this way, but not storing
this offset, Maxim would not perform the offsetting for you.
The result would not be trimmed of at 16bits, but in image terms, would
look just as odd!...

Best Wishes

On Fri, 20 Aug 2004 01:10:30 GMT, "Blaine Sanford"
wrote:

I downloaded the demo of MaximDL today, which is fully functional for 30
days. I opened one of the 32 bit Reg. FITS and the same problems. When I
look at the historgram in Maxim, it looks like only part of the file is
there with the other part missing... my guess is that Maxim is reading only
in 16 bits, so the other 16 bits is being cut off. No amount of historgram
manipulation will make the image appear normal .

If I read it into Maxim, it is obviously being seen as 32-bit data, since the
histogram values are much larger than 65535. But I note the effect you are
talking about, where it looks like all the darker data is missing. If I read
this into Photoshop, the range is shown from -2^31 to +2^31, meaning this is
being seen as signed data. But the FITS header is incorrect, since it is showing
BZERO as 32768, the normal value for a signed 16-bit file.

In other words, Registax is not building a valid 32-bit FITS file. It can be
correctly brought into Photoshop using FITS Liberator. I assume that it is being
recognized as signed because the BZERO value is non-zero, and the sliders allow
you to override any meaning that BZERO has.

_________________________________________________

Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com

"Chris L Peterson" wrote in message
...
On Fri, 20 Aug 2004 01:10:30 GMT, "Blaine Sanford"

wrote:

I downloaded the demo of MaximDL today, which is fully functional for 30
days. I opened one of the 32 bit Reg. FITS and the same problems. When
I
look at the historgram in Maxim, it looks like only part of the file is
there with the other part missing... my guess is that Maxim is reading
only
in 16 bits, so the other 16 bits is being cut off. No amount of
historgram
manipulation will make the image appear normal .

If I read it into Maxim, it is obviously being seen as 32-bit data, since
the
histogram values are much larger than 65535. But I note the effect you are
talking about, where it looks like all the darker data is missing. If I
read
this into Photoshop, the range is shown from -2^31 to +2^31, meaning this
is
being seen as signed data. But the FITS header is incorrect, since it is
showing
BZERO as 32768, the normal value for a signed 16-bit file.

In other words, Registax is not building a valid 32-bit FITS file.

I've been wondering about this, because I've tried the file in about half a
dozen programs that are supposed to read 32 bit FITS, and I kept getting the
same result.

It can be
correctly brought into Photoshop using FITS Liberator.

Can I then resave as a "correct" 32 bit to work in the other programs, or
will this restrict it back down to 16 bit?

Blaine

I assume that it is being
recognized as signed because the BZERO value is non-zero, and the sliders
allow
you to override any meaning that BZERO has.

_________________________________________________

Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com

On Fri, 20 Aug 2004 19:44:47 GMT, "Blaine Sanford"
wrote:

It can be
correctly brought into Photoshop using FITS Liberator.

Can I then resave as a "correct" 32 bit to work in the other programs, or
will this restrict it back down to 16 bit?

No. Photoshop works with 16-bit arrays. When you import 32-bit data, it is
converted to 16-bit. From Photoshop, you can't save files larger than 16 bits.

However... why would you need to? There is really no value to 32-bit data except
for scientific analysis, in which case you are probably doing minimal
processing. What kind of aesthetic imaging can you do where it makes any
difference if you reduce 32-bit data to 16-bit? At display time you reduce it to
8-bit.

_________________________________________________

Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com

"Blaine Sanford" wrote in message
news
Roger,

Here is what I get when I open a Registax 32 bit FIT in MaximDL:

SIMPLE = T
BITPIX = 32
Good. Means it is seen as a 32bit FIT

NAXIS = 2
NAXIS1 = 640
NAXIS2 = 480
BSCALE = 1
BZERO = 32768
This is the 'key' one. The offset here should be 32768, for an unsigned
_16bit_ FITs file. The result as it stands, will be that the image will
have 2147483648 subtracted from the effective pixel values, and then 32768
added!. Try changing it to 2147483648, then saving the file _as 32bit_,
and reopening, or try simply selecting 'process', 'pixel math', havin just
one image selected, and at the bottom of the page (add constant), put in
2147450880 (2147483648-32768). You may then find the image appears OK.
Registax is being 'naughty', using the 32bit format as if it is unsigned,
and then putting the wrong offset into here...

DATE-OBS = '30/12/99'
TIME-OBS = '12:36:17'
OBJECT = ''
INSTRUME = ''
EXPOSURE = ''
OBSERVER = ''
COMMENT = REGISTAX V2.0
COMMENT =

How do I add the offset you speak of? I tried adding it in another
program,
but it didn't seem to have any effect.

Blaine
Hopefully it'll work.

Best Wishes

"Roger Hamlett" wrote in message
...

"Blaine Sanford" wrote in message
ink.net...
I downloaded the demo of MaximDL today, which is fully functional
for 30
days. I opened one of the 32 bit Reg. FITS and the same problems.
When
I
look at the historgram in Maxim, it looks like only part of the file
is
there with the other part missing... my guess is that Maxim is
reading
only
in 16 bits, so the other 16 bits is being cut off. No amount of
historgram
manipulation will make the image appear normal .

Blaine
Have a look at the header information (view, 'fits header window').
What
does the 'bitpix' field show?. Maxim DL4, definately can read and
write
32bit FITs files, and can even read (though not write), 64bit ones. If
the
bitpix field does show that the file has been recognised as a 32bit
type,
it'd be a bit more 'data', as to what is going on.

One possibility that leaps to mind, is that the 32bit format standard,
is
for a signed number. If Registax, was using the 32nd bit as data,
rather
than a sign, it'd require adding a constant offset of 2147483648 to
the
image, to make this work (the same bodge has to be applied to Maxim's
own
16bit FITs files, using 32768). Maxim stores this offset value into
the
FITs header, in the 'BZERO' field, to show that the zero poin is
offset by
this amount. if Registax is using the numbers this way, but not
storing
this offset, Maxim would not perform the offsetting for you.
The result would not be trimmed of at 16bits, but in image terms,
would
look just as odd!...

Best Wishes

"Chris L Peterson" wrote in message
...
On Fri, 20 Aug 2004 19:44:47 GMT, "Blaine Sanford"

wrote:

It can be
correctly brought into Photoshop using FITS Liberator.

Can I then resave as a "correct" 32 bit to work in the other programs, or
will this restrict it back down to 16 bit?

No. Photoshop works with 16-bit arrays. When you import 32-bit data, it is
converted to 16-bit. From Photoshop, you can't save files larger than 16
bits.

However... why would you need to? There is really no value to 32-bit data
except
for scientific analysis, in which case you are probably doing minimal
processing.

You know, I'm thinking in audio terms. I do a bit of sound editing here and
there and all editing is usually done at 32 bit levels and then later
converted to 16 bit for CD and other purposes. In the case of audio,
recording/ editing at the 24/32 bit level does allow some head room and the
audio signal is more dynamic. I was thinking it would be this way also with
32 bit FIT files. Processing at 32 bit would allow more filtering, more
histogram manipulation, etc. than at the 16 bit level. Maybe the difference
isn't enough the justify, but I see large differences between 8 and 16 bit
image processing. It is reasonable to assume that there would also be
differences between 32 and 16 bit. In any case, I haven't been successful
getting this to work, so it looks like I'll have to stick to 16 bit, which,
by the way, seems to show far less problems when switching between the
programs I use.

Blaine


What kind of aesthetic imaging can you do where it makes any
difference if you reduce 32-bit data to 16-bit? At display time you reduce
it to
8-bit.

_________________________________________________

Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com

On Sat, 21 Aug 2004 00:14:23 GMT, "Blaine Sanford"
wrote:

You know, I'm thinking in audio terms. I do a bit of sound editing here and
there and all editing is usually done at 32 bit levels and then later
converted to 16 bit for CD and other purposes. In the case of audio,
recording/ editing at the 24/32 bit level does allow some head room and the
audio signal is more dynamic. I was thinking it would be this way also with
32 bit FIT files. Processing at 32 bit would allow more filtering, more
histogram manipulation, etc. than at the 16 bit level. Maybe the difference
isn't enough the justify, but I see large differences between 8 and 16 bit
image processing. It is reasonable to assume that there would also be
differences between 32 and 16 bit.

The way to approach this is to think in terms of signal-to-noise ratios. When
you are working with stacked video frames, you are probably looking at something
on the order of 1000:1 at best, or about 10 bits. So there is absolutely no
advantage to working with 32-bit data over 16-bit. You are stacking 8-bit data,
so it only takes 256 frames to overflow 16 bits. Therefore, you certainly want
to do your stacking in a 32-bit workspace (as Registax apparently does). But
once you've got your final sum, there is no real S/N penalty in normalizing to
16 bits. So, as you note, it makes good sense to stick with 16-bit data and take
advantage of the much wider support in processing apps.

_________________________________________________

Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com

"Chris L Peterson" wrote in message
...
On Sat, 21 Aug 2004 00:14:23 GMT, "Blaine Sanford"

wrote:

You know, I'm thinking in audio terms. I do a bit of sound editing here
and
there and all editing is usually done at 32 bit levels and then later
converted to 16 bit for CD and other purposes. In the case of audio,
recording/ editing at the 24/32 bit level does allow some head room and
the
audio signal is more dynamic. I was thinking it would be this way also
with
32 bit FIT files. Processing at 32 bit would allow more filtering, more
histogram manipulation, etc. than at the 16 bit level. Maybe the
difference
isn't enough the justify, but I see large differences between 8 and 16
bit
image processing. It is reasonable to assume that there would also be
differences between 32 and 16 bit.

The way to approach this is to think in terms of signal-to-noise ratios.
When
you are working with stacked video frames, you are probably looking at
something
on the order of 1000:1 at best, or about 10 bits. So there is absolutely
no
advantage to working with 32-bit data over 16-bit. You are stacking 8-bit
data,
so it only takes 256 frames to overflow 16 bits. Therefore, you certainly
want
to do your stacking in a 32-bit workspace (as Registax apparently does).
But
once you've got your final sum, there is no real S/N penalty in
normalizing to
16 bits. So, as you note, it makes good sense to stick with 16-bit data
and take
advantage of the much wider support in processing apps.

Well, I've basically given up on trying to find 32 bit compatability between
programs. I tried some of Roger's suggestions for adding to the values, but
it doesn't change anything. 16 bit Registax files DO work well with just
about everything else I use, so I will continue to stick with those. I just
had a thought that maybe I could get the 32 bit files to work but, as I was
not surprised that they wouldn't as I have been down this road many times
before. So, for now on, 16 bit only between programs!

Blaine


_________________________________________________

Chris L Peterson
Cloudbait Observatory
http://www.cloudbait.com

"Roger Hamlett" wrote in message
news

"Blaine Sanford" wrote in message
news
Roger,

Here is what I get when I open a Registax 32 bit FIT in MaximDL:

SIMPLE = T
BITPIX = 32
Good. Means it is seen as a 32bit FIT

NAXIS = 2
NAXIS1 = 640
NAXIS2 = 480
BSCALE = 1
BZERO = 32768
This is the 'key' one. The offset here should be 32768, for an unsigned
_16bit_ FITs file. The result as it stands, will be that the image will
have 2147483648 subtracted from the effective pixel values, and then 32768
added!. Try changing it to 2147483648, then saving the file _as 32bit_,
and reopening, or try simply selecting 'process', 'pixel math', havin just
one image selected, and at the bottom of the page (add constant), put in
2147450880 (2147483648-32768). You may then find the image appears OK.
Registax is being 'naughty', using the 32bit format as if it is unsigned,
and then putting the wrong offset into here...

Still couldn't get it to work, Roger, so I have abandoned any further
workarounds. I have been down this road many times before, adding and
subtracting values, changing historgrams, etc, and was never able to achieve
compatability. So, as Chris suggested, I'll just continue to stick with the
16 bit FITs as they ARE compatable with most of my other images programs.
Thank you in earnest for your suggestions, however.

Blaine



DATE-OBS = '30/12/99'
TIME-OBS = '12:36:17'
OBJECT = ''
INSTRUME = ''
EXPOSURE = ''
OBSERVER = ''
COMMENT = REGISTAX V2.0
COMMENT =

How do I add the offset you speak of? I tried adding it in another
program,
but it didn't seem to have any effect.

Blaine
Hopefully it'll work.

Best Wishes

"Roger Hamlett" wrote in message
...

"Blaine Sanford" wrote in message
ink.net...
I downloaded the demo of MaximDL today, which is fully functional
for 30
days. I opened one of the 32 bit Reg. FITS and the same problems.
When
I
look at the historgram in Maxim, it looks like only part of the file
is
there with the other part missing... my guess is that Maxim is
reading
only
in 16 bits, so the other 16 bits is being cut off. No amount of
historgram
manipulation will make the image appear normal .

Blaine
Have a look at the header information (view, 'fits header window').
What
does the 'bitpix' field show?. Maxim DL4, definately can read and
write
32bit FITs files, and can even read (though not write), 64bit ones. If
the
bitpix field does show that the file has been recognised as a 32bit
type,
it'd be a bit more 'data', as to what is going on.

One possibility that leaps to mind, is that the 32bit format standard,
is
for a signed number. If Registax, was using the 32nd bit as data,
rather
than a sign, it'd require adding a constant offset of 2147483648 to
the
image, to make this work (the same bodge has to be applied to Maxim's
own
16bit FITs files, using 32768). Maxim stores this offset value into
the
FITs header, in the 'BZERO' field, to show that the zero poin is
offset by
this amount. if Registax is using the numbers this way, but not
storing
this offset, Maxim would not perform the offsetting for you.
The result would not be trimmed of at 16bits, but in image terms,
would
look just as odd!...

Best Wishes