<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.hmmessage P
{margin:0px;padding:0px;}
body.hmmessage
{font-size:10pt;font-family:Verdana;}
</style>
Sorry to bother you guys again. This is just to give a little more details about my arithmetic and what I use it for.<br><br>I wrote a GDAL C++ code that solves the following simple problem: <br>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. <br><br>Briefly, the arithmetic that computes the overlap is: <br><br>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, <br>where p and q are integers and f and r are fractions between 0 and 1.<br><br>To keep my email short, I will only deal with the X direction. The Y direction is handled similarly. <br><br>Let SrcXRes be the spatial resolution in the X direction for the source image <br>and DstXRes the spatial resolution in the X direction for the destination image.<br>(For the images I am using SrcXRes is 25m and DstXRes is 10000m.)<br><br>Then, I use the number f + 1/2*(SrcXRes/DstXRes) and f - 1/2*(SrcXRes/DstXRes) to decide whether the pixel<br>is inside or outside the destination pixel and compute the fraction that's inside accordingly.<br>For example, if f + 1/2*(SrcXRes/DstXRes) is greater than 1.0, then the fraction of the source pixel that's inside is:<br><br><div align="center">(1-f+ 1/2*(SrcXRes/DstXRes))/(SrcXRes/DstXRes)<br></div><br>The other cases are handled similarly.<br><br>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.<br><br> 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.<br><br>Am I doing something wrong in my arithmetic? Should I apply an average filter to smoothen the image? <br>Any other ideas or thoughts on how to proceed are very appreciated.<br><br>Thank you all in advance.<br><br>~Belaid.<br><br><br><br><br> <br><br><br><hr id="stopSpelling">From: belaid_moa@hotmail.com<br>To: chris.barker@noaa.gov; gdal-dev@lists.osgeo.org<br>Subject: RE: [gdal-dev] pixel/line mapping for two images.<br>Date: Wed, 16 Sep 2009 19:39:20 +0000<br>CC: <br><br>
<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Verdana;}
</style>
<br>Thank you very much very much Chris for clarifying things. Could you please let me know which file contains the anti-aliasing code?<br>I did the arithmetic to compute the overlap but somehow I keep getting non-smooth areas <br>(areas with very sharp boundaries). The spatial resolution of the source image is so high that the source pixel is never <br>shared between two pixels in the destination image (according to my arithmetic ). Is this suppose to be the case? <br>The anti-aliasing code will help me to check my arithmetic. <br><br>With best regards.<br>Belaid Moa.<br><br> <br><br>> Date: Wed, 16 Sep 2009 09:58:31 -0700<br>> From: Chris.Barker@noaa.gov<br>> Subject: Re: [gdal-dev] pixel/line mapping for two images.<br>> To: belaid_moa@hotmail.com; gdal-dev@lists.osgeo.org<br>> <br>> Belaid MOA wrote:<br>> > Thanks for the reply. I do not see how anti-aliasing techniques could be <br>> > used here.<br>> <br>> anti-aliasing when warping rasters requires computing how much the <br>> pixels of the source and destination overlap each-other.<br>> <br>> > Does anyone else have simple answers to the two elementary questions?<br>> <br>> sure:<br>> <br>> > > > According to GDAL code, a pixel/line (i,j), more precisely its center<br>> > > > (i+0.5,j+0.5), of the first image is mapped to the pixel/line (p,q) <br>> > of the<br>> > > > second image, where p and q are doubles that usually have fraction <br>> > parts.<br>> > > > My questions are: what is the meaning for these fractions?<br>> <br>> the point in the middle of a pixel in the source raster represents a <br>> particular lat-long location -- p and q are the location in the second <br>> image for the same lat-long -- chances are slim that it's going to land <br>> exactly on a pixel boundary, hence the fraction. Just like the middle of <br>> the source pixel is i+0.5, j+0.5, the middle of a destination pixel <br>> would be p+0.5, q+0.5.<br>> <br>> > Is it possible to use these fractions to compute the overlap between<br>> > the pixels of the two images using GDAL?<br>> <br>> yup -- think about the above, and do a little arithmatic (which i s the <br>> arithmetic done in the anti-aliasing code.<br>> <br>> HTH,<br>> <br>> -Chris<br>> <br>> <br>> <br>> -- <br>> Christopher Barker, Ph.D.<br>> Oceanographer<br>> <br>> Emergency Response Division<br>> NOAA/NOS/OR&R (206) 526-6959 voice<br>> 7600 Sand Point Way NE (206) 526-6329 fax<br>> Seattle, WA 98115 (206) 526-6317 main reception<br>> <br>> Chris.Barker@noaa.gov<br>> <br><br><hr>New! Hotmail sign-in on the <a href="http://go.microsoft.com/?linkid=9677401">MSN homepage.</a><br /><hr />Less clicking: Hotmail access on the new <a href='http://go.microsoft.com/?linkid=9677398' target='_new'>MSN homepage.</a></body>
</html>