[Gdal-dev] SAR Ceos border pixels
alexamici at fastwebnet.it
Tue Aug 24 17:28:27 EDT 2004
On Tuesday 24 August 2004 20:20, Gillian Walter wrote:
> I don't know if anyone on this list knows anything about the history of
> the SAR ceos format and its variants, but just in case, here goes (I'd
> be grateful for even partial answers to any of the following questions):
if partial and not completely to the point is ok, then i'll share what i
> I have been looking at the SAR ceos format driver after running into
> some problems with Alaska SAR Facility (ASF) data, and am a bit confused
> about how gdal is interpreting some of the fields. I have been using
> the CEOS-SAR-CCT spec (March 1989) and ASF slightly non-ceos format spec
> (see the reference documents under
> http://www.asf.alaska.edu/sitemap.html) as reference.
i used heavily ERS1/2 complex SAR data produced by UK, D and I facilities and
distributed in CEOS format. i also had a quick look at a Radarsat SAR dataset
(i assume, you are interested in Radarsat data) that appeared to have a
similar CEOS structure.
last time i checked the specs relative to the ERS CEOS format were located at
> In particular,
> I'm looking at the following fields of the file descriptor record of the
> imagery options file:
> 37 (bytes 237-244): Number of lines per data set (one channel) in the
> file (excluding border lines)
> 38 (bytes 245-248): Number of left border pixels per line
> 39 (bytes 249-256): Total number of data groups (or pixels) per line per
> SAR channel
> 40 (bytes 257-260): Number of right border pixels per line
> 41 (bytes 261-264): Number of top border lines
> 42 (bytes 265-268): Number of bottom border lines
> My questions are:
> 1) What is the definition of a "border pixel" (padding, invalid data,
> etc.), and is the interpretation consistent between the different
> flavours of SAR ceos (I've looked at a few specs and haven't found any
> info on what the border pixels/lines are meant to be, except in the ASF
> MapProjectDataRecord spec which mentions "black edges", which I take to
> mean zero padding)?
in my experience (100+ images) i can only recall zero padding borders.
> 2) Should border pixels be read in? Gdal seems to use fields 37 and 39
> to determine rasterYsize and rasterXsize, which I think means that all
> pixels (including border pixels) get read in, and some lines (either
> only the valid lines, or the top border lines + (number of valid lines -
> top border lines) valid lines depending on what line offset is used for
> the first line) get read in. Gdal reads in the top, bottom, right, left
> border pixel values, but doesn't seem to use them anywhere as far as I
> can tell.
again, from experience i'm ready to bet that gdal reads the whole image
without any use of the 'border' metadata.
> 3) When do GCP pixel/line coordinates include the border pixel/lines?
> The ASF spec indicated that GCPs in fields 68-75 of the Map projection
> record include the black edges (which I'm assuming are the border
> pixels), but that the corners in fields 18-25 of the Facility data
> record do not include black fill. I couldn't find any mention of the
> border pixels in the GCP sections of the SAR CCT spec.
no idea on this one.
> 4) Are border pixels/lines often non-zero in actual data?
i can only speak about ERS data, but i recall only one image with a black
border. we fixed our tools to cope with that and we didn't care much
afterwards. YMMV with other data sources thou.
that's all and i don't have access to the data and to the tools anymore :-(
More information about the Gdal-dev