Hi Matins, Slight variations of the pixel colour may come about due to GDAL interpolating data, interpolation done with VPB, or the edge boundary equalization. The small variation you are seeing might simply be down to this, it's not something at this stage I'd even flag up as a problem. It certainly doesn't looked to be the corner equalization bug, as this just effects the corners.
BTW, the way is there a reason for the image being pixelated? VPB typically generates databases that use linear texture filtering. Robert. 2009/3/19 Martins Innus <min...@ccr.buffalo.edu> > Robert, > Thanks. Using -e with appropriate options did exactly what I wanted, > except for a slight error on the edges of the created images. If i overlay > the created image tiles from the highest resolution level on top of the > original source imagery, they are pixel to pixel exact except for a 1 pixel > strip all the way around the image. > It appears that the edge values are an average of what the pixel > value actually should be and the pixel directly adjacent to it but what > should be the next tile. > If you layer the attached good and bad images on top of each other > in an image viewer and toggle back and forth you can see the pixels > changing. > The good image is just the original source imagery zoomed in. The > bad image shows the vpb generated tile overlayed on the left side. > > I saw the "corner equalization bug" posts, but this seems like a > different issue. > > This is under Redhat Enterpise Linux, x86_64, with OSG 2.8 and VPB svn of a > couple days ago. > > Martins > > > Robert Osfield wrote: > >> Hi Martins, >> >> You could try to use the -e option. It takes lat/longs as input. I don't >> know if it'll pad though, as I suspect it won't unless the at least some of >> the input data covers the region. If you want to force the resolution to >> be the same then just use the image and height res option. I can't recall >> what they off the top of my head, run osgdem --help to list them all. >> >> Robert. >> >> On Mon, Mar 16, 2009 at 6:12 PM, Martins Innus >> <min...@ccr.buffalo.edu<mailto: >> min...@ccr.buffalo.edu>> wrote: >> >> Hello, >> I'm using VPB to generate a terrain database with 2ft >> resolution elevation data and 1 ft resolution imagery. What I'm >> trying to do is make the imagery in the highest resolution tiles >> have the exact same resolution as the source imagery and also still >> be a power of 2 for the image tiles. >> I've verified that if I take a small input area where the >> source imagery dimensions are a power of 2, I get what i want for >> the final model. >> It seems that if I could tell VPB to "pad out" the extents of >> my input data to a power of 2 that should work as well. I don't >> care if its black or garbage or whatever. >> >> Would the "-e" option do what I want if I specify extents >> larger than the input data? I'm about to give that a try but it >> takes about three days for this job to run to completion, so I >> figured I would ask if anyone has tried to do the same thing. >> >> Thanks for any insight. >> >> Martins >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> <mailto:osg-users@lists.openscenegraph.org> >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
