A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Astronomy and Astrophysics » FITS
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

Images getting shifted and wrapping on themselves...?



 
 
Thread Tools Display Modes
  #1  
Old August 27th 08, 01:06 AM posted to sci.astro.fits
gberz3
external usenet poster
 
Posts: 11
Default 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!
  #2  
Old August 27th 08, 04:21 AM posted to sci.astro.fits
Steve Allen
external usenet poster
 
Posts: 37
Default [fitsbits] Images getting shifted and wrapping on themselves...?

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
  #3  
Old August 27th 08, 05:04 AM posted to sci.astro.fits
gberz3
external usenet poster
 
Posts: 11
Default Images getting shifted and wrapping on themselves...?

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.

  #4  
Old August 27th 08, 05:26 AM posted to sci.astro.fits
gberz3
external usenet poster
 
Posts: 11
Default Images getting shifted and wrapping on themselves...?

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.
  #5  
Old August 27th 08, 08:05 AM posted to sci.astro.fits
Harro Verkouter
external usenet poster
 
Posts: 2
Default [fitsbits] Images getting shifted and wrapping on themselves...?

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

  #6  
Old August 27th 08, 01:55 PM posted to sci.astro.fits
gberz3
external usenet poster
 
Posts: 11
Default Images getting shifted and wrapping on themselves...?

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".
  #7  
Old August 27th 08, 02:33 PM posted to sci.astro.fits
William Pence[_2_]
external usenet poster
 
Posts: 44
Default [fitsbits] Images getting shifted and wrapping on themselves...?

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.

  #8  
Old August 27th 08, 09:41 PM posted to sci.astro.fits
gberz3
external usenet poster
 
Posts: 11
Default Images getting shifted and wrapping on themselves...?

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.
  #9  
Old August 28th 08, 04:33 AM posted to sci.astro.fits
William Pence[_2_]
external usenet poster
 
Posts: 44
Default [fitsbits] Images getting shifted and wrapping on themselves...?

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.

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Help! My poles are all shifted! Rujo King Astronomy Misc 3 October 28th 03 10:38 PM


All times are GMT +1. The time now is 08:05 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 SpaceBanter.com.
The comments are property of their posters.