3

I have the following GeoTIFF which contains white around the sides. The raster band info is as follows for the white area

Band 1    254
Band 2    254
Band 3    254
Band 4    255

enter image description here

To try and correct this I have used the following gdal command

nearblack input.tif" -near 5 -white -setalpha

which has returned a result with white bits. What have I done wrong? Most of the white areas were eliminated but there's one remaining. When I look at its band information its

Band 1    254
Band 2    254
Band 3    254
Band 4    255

which is no different to the other white areas that were eliminated. So why was this different?

2
  • You did not notice that there is also another missing area, a small triangle above the Victoria Park.
    – user30184
    Commented May 16 at 20:37
  • @user30184 you are correct! I had missed that
    – user832190
    Commented May 16 at 21:15

1 Answer 1

3

That is/was a known issue with nearblack. See the discussion in https://github.com/OSGeo/gdal/issues/6264 and the image in the comment https://github.com/OSGeo/gdal/issues/6264#issuecomment-1569883495.

The new filling option -alg floodfill https://gdal.org/programs/nearblack.html#cmdoption-nearblack-alg should help with that issue. If it does not, try gdal_footprint https://gdal.org/programs/gdal_footprint.html instead.

-alg twopasses|floodfill

Added in version 3.8.

Selects the algorithm to apply.

twopasses uses a top-to-bottom pass followed by a bottom-to-top pass. This is the only algorithm implemented before GDAL 3.8. It may miss with concave areas. The algorithm processes the image one scanline at a time. A scan "in" is done from either end setting pixels to black or white until at least "non_black_pixels" pixels that are more than "dist" gray levels away from black, white or custom colors have been encountered at which point the scan stops. The nearly black, white or custom color pixels are set to black or white. The algorithm also scans from top to bottom and from bottom to top to identify indentations in the top or bottom.

floodfill (added in GDAL 3.8) uses the Flood Fill algorithm and will work with concave areas. It requires creating a temporary dataset and is slower than twopasses. When a non-zero value for -nb is used, twopasses is actually called as an initial step of floodfill.

For troubleshooting run the command with --debub on.

The debug info shows that with the floodfill option GDAL needs to create a new file at 50% progress.

0...10...20...30...40...50GDAL: GDALDriver::Create(GTiff,nearblackout.tif.visited.tif,12000,12000,1,Byte,000001BC97402E00)
7
  • Thanks but if I add -alg floodfill to my command I'm getting this error 0...10...20...30...40...50ERROR 4: Attempt to create new tiff file `C:\AppData\Local\Temp\OUTFILE.tif_25572_1.tif' failed: No error
    – user832190
    Commented May 17 at 9:33
  • It works for me. I added an advice for debugging and some log data from my successful run. Test again by using some other target directory than C:\AppData\Local\Temp just to make sure that it does not require some special rights.
    – user30184
    Commented May 17 at 9:58
  • Strangely, I don't know why its saying C:\AppData\Local\Temp as I havent set that as the target directory. I've set "D:\" - my external harddrive
    – user832190
    Commented May 17 at 10:00
  • Then it must be some GDAL temp directory. I do not know how it is configured. EDIT: gdal.org/user/configoptions.html and "CPL_TMPDIR=<dirname> By default, temporary files are written into current working directory. " Maybe that is not true but the Windows TEMP or TMP is used instead.
    – user30184
    Commented May 17 at 10:06
  • But then C:\AppData\Local\Temp looks odd. Windows TEMP is usually under C:\Users\user_xxxx\AppData...
    – user30184
    Commented May 17 at 10:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.