[Gdal-dev] Missing pixels after warp

[Stephen Woodbridge]

Frank Warmerdam wrote:
> Stephen Woodbridge wrote:
>> Hi,
>>
>> I used gdal warp to mosaic some images and I seem to have some bit-rot 
>> along the seams.
>>
>> http://imaptools.com/temp/missing-pixels.png
>>
>> The upper image is a 2 meter/pixel image that was stretched into a 1 
>> meter/pixel file. Then the lower image which is 1 meter/pixel was 
>> mosaiced into the same file.
>>
>> This problem is probably exaggerated but the stretching the image into 
>> the 1 meter/pixel file.
>>
>> I have not had a chance to recreate this and look at the original 
>> source files to see what they look like, but I'm wondering is anyone 
>> has any tricks or ideas on how to avoid this?
> 
> Steve,
> 
> This looks like quite a serious issue.  I'd guess there are pixels being
> identified as nodata, though it is hard to be sure.
> 
> If you can boil this down to a simple process to reproduce I'd be 
> interested
> in digging into it.  There is at least one somewhat related sounding bug
> report in trac I hope to dig into.
> 
> Best regards,
> 
Frank,

Thank you for the offer. I was able to track the problem back to the 
source tiles and it is a nearblack issue with some tiles.

This brings up couple of interesting problems associated with using 
nearblack. The imagery I'm working with is CCM files and as you know 
these are mosaics of DOQQ or equivalent tiles. So the one example that I 
traced back had an image with a notch like where "n" is nearblack:

         nnnnnnnnnnnnn          nnnnnnnnnnnnnnn
         n+---------+n          n+-----------+n
         n|         |n     A    n|           |n
         n|         |n          n|           |n
         n|         |nnnnnnnnnnnn|           |nnnnnnnnnnnnnnn
         n|         +------------+           +-------------+n
         n|                                                |n
         n|                                                |n
         n+------------------------------------------------+n
         nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

1) nearblack scans rows from right to left and left to right and stops 
its scan after eating some pixels of good data. So it will never process 
a notch like area "A" above or a hole in the imagery (not that I have 
that case).

2) Notice my comment about eating some good pixels. nearblack does not 
implement a look ahead, it destructively eats (sets to black) good 
pixels and counts them. After it has reached some threshold it decides 
that it is in real data and terminates that scan. What is should do is 
trigger a look ahead if it finds a pixel outside the near black 
threshhold, to see if it is a small outlier or real data. Yes this would 
make it marginally slower but most of the time you would not do the look 
ahead, and the current algorithm does the same scan as a look behind.

3) it would be a nice feature to add to gdalwarp and gdal_translate to 
be able to define something like:
    -srcnodata <5
that would treat all values less than 5 as nodata in the source image. 
This has some obvious downsides of setting possible nearblack good data 
in the interior to black, but I think it would be generally useful for a 
lot of situations.

Thoughts?

-Steve