Sorry to bother you guys again. This is just to give a little more details
about my arithmetic and what I use it for.
I wrote a GDAL C++ code that solves the following simple problem:
take two images, a source image with spatial resolution 25mx25m (high
resolution) and a destination image with spatial resolution 10000mx10000m (low
resolution) and scale the source image so that the values of the pixels in the
source image that are mapped to the same pixel P in the destination image sum
up to the value of P. As a side note, the two images have different
projections.
Briefly, the arithmetic that computes the overlap is:
Given the pixel (i,j) in the source image, I take the center (i+0.5,j+0.5) and
mapping it to (p+f,q+r) in the destination image,
where p and q are integers and f and r are fractions between 0 and 1.
To keep my email short, I will only deal with the X direction. The Y direction
is handled similarly.
Let SrcXRes be the spatial resolution in the X direction for the source image
and DstXRes the spatial resolution in the X direction for the destination image.
(For the images I am using SrcXRes is 25m and DstXRes is 10000m.)
Then, I use the number f + 1/2*(SrcXRes/DstXRes) and f - 1/2*(SrcXRes/DstXRes)
to decide whether the pixel
is inside or outside the destination pixel and compute the fraction that's
inside accordingly.
For example, if f + 1/2*(SrcXRes/DstXRes) is greater than 1.0, then the
fraction of the source pixel that's inside is:
(1-f+ 1/2*(SrcXRes/DstXRes))/(SrcXRes/DstXRes)
The other cases are handled similarly.
As a side note, the reason for computing the fraction that's inside is that it
simplifies a lot my arithmetic and thus my code.
As you can see, the ratio 1/2*(SrcXRes/DstXRes) is so small that I do not get
smooth image (image with clear blocks of 10kmx10km rotated because of the
projections difference). When I increase this ratio (just for testing), I get
smooth image.
Am I doing something wrong in my arithmetic? Should I apply an average filter
to smoothen the image?
Any other ideas or thoughts on how to proceed are very appreciated.
Thank you all in advance.
~Belaid.
From: belaid_...@hotmail.com
To: chris.bar...@noaa.gov; gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] pixel/line mapping for two images.
Date: Wed, 16 Sep 2009 19:39:20 +0000
CC:
Thank you very much very much Chris for clarifying things. Could you please let
me know which file contains the anti-aliasing code?
I did the arithmetic to compute the overlap but somehow I keep getting
non-smooth areas
(areas with very sharp boundaries). The spatial resolution of the source image
is so high that the source pixel is never
shared between two pixels in the destination image (according to my arithmetic
). Is this suppose to be the case?
The anti-aliasing code will help me to check my arithmetic.
With best regards.
Belaid Moa.
> Date: Wed, 16 Sep 2009 09:58:31 -0700
> From: chris.bar...@noaa.gov
> Subject: Re: [gdal-dev] pixel/line mapping for two images.
> To: belaid_...@hotmail.com; gdal-dev@lists.osgeo.org
>
> Belaid MOA wrote:
> > Thanks for the reply. I do not see how anti-aliasing techniques could be
> > used here.
>
> anti-aliasing when warping rasters requires computing how much the
> pixels of the source and destination overlap each-other.
>
> > Does anyone else have simple answers to the two elementary questions?
>
> sure:
>
> > > > According to GDAL code, a pixel/line (i,j), more precisely its center
> > > > (i+0.5,j+0.5), of the first image is mapped to the pixel/line (p,q)
> > of the
> > > > second image, where p and q are doubles that usually have fraction
> > parts.
> > > > My questions are: what is the meaning for these fractions?
>
> the point in the middle of a pixel in the source raster represents a
> particular lat-long location -- p and q are the location in the second
> image for the same lat-long -- chances are slim that it's going to land
> exactly on a pixel boundary, hence the fraction. Just like the middle of
> the source pixel is i+0.5, j+0.5, the middle of a destination pixel
> would be p+0.5, q+0.5.
>
> > Is it possible to use these fractions to compute the overlap between
> > the pixels of the two images using GDAL?
>
> yup -- think about the above, and do a little arithmatic (which i s the
> arithmetic done in the anti-aliasing code.
>
> HTH,
>
> -Chris
>
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> chris.bar...@noaa.gov
>
New! Hotmail sign-in on the MSN homepage.
_________________________________________________________________
New: Messenger sign-in on the MSN homepage
http://go.microsoft.com/?linkid=9677403
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
