Opened 12 years ago

Closed 12 years ago

Last modified 8 years ago

#3222 closed defect (fixed)

warp masking problems

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone:
Component: Algorithms Version: unspecified
Severity: normal Keywords: warp
Cc: vjetly



When warping from image ‘a’ to ’b’, gdalwarp with cutline and cblend options also draws in black values from ‘b’ along the cutline. I’m attaching sample images to illustrate the issue. So when I run something like this:

gdalwarp E:\DEV\2009\Frank\cutline\p0018.tif E:\DEV\2009\Frank\cutline\R021C058_output.tif -cutline E:\DEV\2009\Frank\cutline\cutline.shp -cblend 10

the black area from the existing image (R021C058_output) bleeds in along the cutline. We want to avoid this somehow to keep the resulting mosaick clean on the outer boundary of the cutline. I tried using the dstnodata option like this so that black pixels are not used in the blending:

gdalwarp E:\DEV\2009\Frank\cutline\p0018.tif E:\DEV\2009\Frank\cutline\R021C058_output.tif -cutline E:\DEV\2009\Frank\cutline\cutline.shp -cblend 10  -dstnodata “0 0 0”

However this produces very odd output where the cutline seems to have been ignored in some areas (eastern straight edge of the cutline) and applied as a hard cutline (eastern sloping edge of the cutline) but offset from the actual cutline by the blend distance. It is difficult to explain but if you run the command above and look along the eastern edge of the cutline in the mosaic, you should be able to see this.

Could you please take a look at this?

Thanks, Vikalpa

Change History (4)

comment:1 Changed 12 years ago by warmerdam

Cc: vjetly added
Status: newassigned

It is unclear yet whether I can release the data.

But it seems there were two problems.

The first was already noticed in the past as per the comment:

 /* -------------------------------------------------------------------- */
-/*      Don't generate output pixels for which the destination valid    */
-/*      mask exists and is already set.                                 */
-/*                                                                      */
-/*      -- NFW -- FIXME: I think this test is in error.  We should,     */
-/*      generally, be pasteing over existing valid data.                */
-/* -------------------------------------------------------------------- */
-            iDstOffset = iDstX + iDstY * nDstXSize;
-            if( poWK->panDstValid != NULL
-                && (poWK->panDstValid[iDstOffset>>5]
-                    & (0x01 << (iDstOffset & 0x1f))) )
-                continue;

But apparently I didn't do anything at the time wanting to review the reason the code was there more closely. I can see no reason for it, and I have removed it. It also occured in three similar functions and I have removed it from them as well.

The second issue was that panBandMask was not initialized for the computation of panDstValid. This results in random stripping and other effects.

The panDstValid computation was also improperly pre-clearing panDstValid which would be a problem if a DstValid? mask were passed into the warper though this issue did not manifest for Vikalpa. I did however fix it too (the bulk of the gdalwarpoperation.cpp changes).

The changes are in trunk (r18012), and 1.6 (r18013).

comment:2 Changed 12 years ago by warmerdam

Data to reproduce the problem(s) at:

comment:3 Changed 12 years ago by warmerdam

Resolution: fixed
Status: assignedclosed

comment:4 Changed 8 years ago by Even Rouault

Milestone: 1.6.4

Milestone 1.6.4 deleted

Note: See TracTickets for help on using tickets.