Images getting shifted and wrapping on themselves...?

Hi All,

I have written an application to read FITS files. I now have an
anomaly where some images have a "split" in them. Basically it
appears that the image is shifted to the right or left by so many
pixels and "wraps" around. This doesn't happen, however if I open it
in GIMP using the FITS plugin, or with various other FITS Viewers.
I'm curious as to what could be happening. Is there some type of
"key" in the data that would tell me about a particular offset? I've
checked headers between "good" files and the "split" ones and there
seems to be no relevant differences. In fact, most of the split
images only have SIMPLE, BITPIX, NAXIS, NAXIS1, NAXIS2, and no other
data.

Any input would be most appreciated.


Best!

On Tue 2008-08-26T17:06:53 -0700, gberz3 hath writ:
appears that the image is shifted to the right or left by so many
pixels and "wraps" around.

BITPIX = 8 means unsigned integers
BITPIX = 16 or 32 means signed integers

BZERO and BSCALE can be used to modify the meaning of the
linear transformation.

--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855
University of California Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

On Aug 26, 11:21*pm, Steve Allen wrote:
BITPIX = 8 means unsigned integers
BITPIX = 16 or 32 means signed integers

But this is as regards the actual values...no? My concern isn't the
values, but their relative positions. I'm guessing there is something
I am severely misunderstanding when it comes to FITS standards.

BZERO and BSCALE can be used to modify the meaning of the
linear transformation.

At this stage, the application doesn't understand these values.
However, the images in question don't make use them either.

Also, I have some with negative BITPIX values, which seem to indicate
float values (still not relevant to the location). I suppose I can
implement a generic shift of sorts, but I'd really like to know what
to key off of officially, before I go messing with that portion of my
code.


Thanks for your input, btw.

Hi gberz3,

I would look at the CRPIXn value - which defines the reference pixel for
axis #n. A non-zero (or non-one) value [I forget if it's zero or
one-based] would appear as a shift in the axis: the value of this
keyword defines the 'logical' zero-point on axis #n.

hth,

harro verkouter

gberz3 wrote:
Hi All,

I have written an application to read FITS files. I now have an
anomaly where some images have a "split" in them. Basically it
appears that the image is shifted to the right or left by so many
pixels and "wraps" around. This doesn't happen, however if I open it
in GIMP using the FITS plugin, or with various other FITS Viewers.
I'm curious as to what could be happening. Is there some type of
"key" in the data that would tell me about a particular offset? I've
checked headers between "good" files and the "split" ones and there
seems to be no relevant differences. In fact, most of the split
images only have SIMPLE, BITPIX, NAXIS, NAXIS1, NAXIS2, and no other
data.

Any input would be most appreciated.


Best!
_______________________________________________
fitsbits mailing list

http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits

On Aug 27, 3:05*am, Harro Verkouter wrote:

I would look at the CRPIXn value - which defines the reference pixel for
axis #n. A non-zero (or non-one) value [I forget if it's zero or
one-based] would appear as a shift in the axis: the value of this
keyword defines the 'logical' zero-point on axis #n.


Except, that information isn't present in these particular images.
The images I'm using have a very simple header:

SIMPLE =
T
BITPIX = -16 (a couple have
-32)
NAXIS =
2
NAXIS1 =
600
NAXIS2 = 532


Gimp and SAOImage DS9 read them just fine, however my app skews them.
It obviously has something to do with an appropriate "read" mechanism,
but I'm not sure what the difference is supposed to be. It's also of
note that some of the images are actually turned on their sides by 90
degrees for no apparent reason in SAO and GIMP. Obviously they are
keying off something in order to perform "correction".

A phase shift like you describe in the image could be caused if the byte
offset in the file to the start of the image bytes is calculated
incorrectly. The image always starts at the beginning of a 2880-byte
FITS block, e.g., at byte 2880, 5760, 8640, ..., etc. and is the first
FITS block following the header block that contains the END keyword.

Bill Pence

gberz3 wrote:
Hi All,

I have written an application to read FITS files. I now have an
anomaly where some images have a "split" in them. Basically it
appears that the image is shifted to the right or left by so many
pixels and "wraps" around. This doesn't happen, however if I open it
in GIMP using the FITS plugin, or with various other FITS Viewers.
I'm curious as to what could be happening. Is there some type of
"key" in the data that would tell me about a particular offset? I've
checked headers between "good" files and the "split" ones and there
seems to be no relevant differences. In fact, most of the split
images only have SIMPLE, BITPIX, NAXIS, NAXIS1, NAXIS2, and no other
data.

Any input would be most appreciated.

On Aug 27, 9:33*am, William Pence wrote:
A phase shift like you describe in the image could be caused if the byte
offset in the file to the start of the image bytes is calculated
incorrectly. *The image always starts at the beginning of a 2880-byte
FITS block, e.g., at byte 2880, 5760, 8640, ..., etc. *and is the first
FITS block following the header block that contains the END keyword.


Right, and I've verified the 2880 lengths. However, if it were an
offset issue, then it would simply chop off the remainder, not wrap it
around. Is that not correct? The image is actually shifted by "so
many" pixels, and instead of an empty/black/white strip on the left,
it draws the remainder of the image back on that side -- as if it were
on a cylinder of some sort.

gberz3 wrote:
On Aug 27, 9:33 am, William Pence wrote:

A phase shift like you describe in the image could be caused if the byte
offset in the file to the start of the image bytes is calculated
incorrectly. The image always starts at the beginning of a 2880-byte
FITS block, e.g., at byte 2880, 5760, 8640, ..., etc. and is the first
FITS block following the header block that contains the END keyword.



Right, and I've verified the 2880 lengths. However, if it were an
offset issue, then it would simply chop off the remainder, not wrap it
around. Is that not correct?

That is not correct. If there are extra bytes at the beginning of the
image data array, this will shift the image in all the rows to the
right, and the pixels that fall off the right hand edge will be wrapped
around and appear on the left side of the image on the next row.

When you display the image, there are probably some non-image pixels
(maybe all with zero value) in the first or last row(s) of the image.
If you count the number of these extraneous pixels, and multiply by the
pixel byte size, this will tell you the size of the byte offset error.
If the blank pixels are at the beginning (bottom) of the image, your
calculated byte offset to the start of the image is too small, and the
opposite if the blank pixels are in the last row (top) of the image.