Hello,


Yes my images (single band greyscale) come from the Clementine mission and are 
processed first with a) four corner points as gcps are inserted in the TIF file 
and b) warped so that the image's upper raster is aligned west to east:



gdal_translate -q -of GTiff -gcp 1 1 $UL_LON $UL_LAT -gcp $image_width 1 
$UR_LON $UR_LAT -gcp 1 $image_height $LL_LON $LL_LAT -gcp $image_width 
$image_height $LR_LON $LR_LAT $tif_file $geo_file



gdalwarp -r near -tps -t_srs EPSG:4326 -dstalpha $geo_file $warp_file



The warping introduces new pixels which are black (value 0) but this I am 
handling through the "-dstalpha" flag that adds a second band of pixel alpha 
values: 0 for invisible pixels, 255 for visible.



The blank pixels are not seen. This works well when a background image is used 
to cover the empty areas in the mission's imagery. The problem is with two 
images that are aligned (and they align great), and just the boundary pixels. 
And it is really noticeable in images aligned side-by-side.



Now my question:



I have seen the "nodata" flags in the gdalbuildvrt command but I just don't 
understand how to use them. For example in the man page for gdalbuildvrt



-srcnodata "<value>[ <value>]..."

              Set nodata values for input bands...



What does this mean? My input "data" values - pixels in a greyscale band - 
range from 0 to 255. Using the value for the pixels added by  the warp command 
does not make sense to me as the original raster could also be using that value.



Anyway, thanks for the help.



Jose Rodriguez

jose.m.rodriguez220....@us.navy.mil<mailto:jose.m.rodriguez220....@us.navy.mil>





> Hi Jose,



> I'm not sure if this is happening in your case, but I've seen something 
> similar with rotated rasters that used 0 or a negative value for the outside 
> pixels. If you're doing interpolation or reprojection, those values will be 
> used in the computation and affect neighboring > pixels. But if you set the 
> nodata value on the inputs, GDAL will (usually?) mask out those pixels so 
> they don't affect the output.



> Laurentiu



> On Wed, Dec 4, 2024, at 18:14, Rodriguez, Jose M CTR (USA) via gdal-dev wrote:

> > Hello,

> >

> > I have been using GDAL to process a large collection of images of the Moon 
> > with the ultimate goal of generating a tile set for use in CesiumJS.

> >

> I use gdalbuildvrt to build of virtual mosaic of the images in question and 
> then use gdal2tiles.py to generate the tile set. All these steps work and I 
> have a working tile set of the Moon. But I am not happy with one result: the 
> edges of the images, when zoomed in, can easily be seen as darker pixels (for 
> images that overlap).

> >

> > I have tried different values for the --resampling parameter of 
> > gdal2tiles.py and the -resolution parameter of gdalbuildvrt with no effect. 
> > Am I missing something that could help here? Any suggestions on how can 
> > this be addressed?

> >

> > (Also is there a recommended way to attaching images to this list? If

> > I attach a small screen capture to this email what happens?)

> >

_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to