Ticket #1905 (new enhancement)

Opened 9 months ago

Last modified 7 months ago

[PATCH] nearblack to also set output black/white as nodata

Reported by: maphew Assigned to: rouault
Priority: normal Milestone: 1.6.0
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords:
Cc: warmerdam

Description

Please consider enhancing nearblack so that the output bordering areas have the NODATA flag set as well as being converted to pure black or white.

We frequently deal with satellite images which have interior lakes or shadows with values of 0,0,0 so it is not as simple as just saying "treat all 0,0,0 as transparent". If nearblack set the bordering area to be nodata, to those programs aware of the geotiff nodata flag, then we can just say "treat nodata as transparent" and not jump through any hoops to set interior black to black+1 and then running nearblack.

thanks.

Attachments

gdal_svn_trunk_nearblack_nodata_1905.patch (4.8 kB) - added by rouault on 10/28/07 13:51:49.

Change History

10/28/07 13:51:25 changed by rouault

  • milestone set to 1.5.0.

In the enclosed patch, I'm adding a -set_to_nodata option to fulfill the behaviour described in the bug report

10/28/07 13:51:49 changed by rouault

  • attachment gdal_svn_trunk_nearblack_nodata_1905.patch added.

10/28/07 13:55:17 changed by rouault

  • owner changed from warmerdam to rouault.
  • cc set to warmerdam.
  • summary changed from nearblack to also set output black/white as nodata to [PATCH] nearblack to also set output black/white as nodata.

10/28/07 14:04:40 changed by warmerdam

Even,

I think Matt was suggesting that we use GDALSetNoDataValue() to mark black (or white) as the nodata value, rather than querying existing nodata values and setting values to that.

10/28/07 14:11:45 changed by rouault

Hum, I'm not sure. If he has lakes whose value is 0,0,0 and we set nodata as 0, then the lakes will be considered as transparent. So the nodata value needs to be different from 0 in that situation too.

10/28/07 14:24:55 changed by warmerdam

Even, that is true, but the main goal of nearblack is to set values near black or white to an exact color so it can be treated as nodata. In any event, I'm not overly keen on your suggested change unless you have a need for it. I can see why Matt wants what he wants, but I'm even a bit nervous about doing it by default.

10/28/07 14:33:40 changed by rouault

I don't have a personnal need for that and I'm aware it might be confusing. Hopefully Matt can grab the patch and it will fulfill its needs... (To be precise, unless you specify -set_to_nodata, nearblack behaviour is unchanged)

10/30/07 12:29:53 changed by maphew

Even, thanks for taking a crack at this.

Thinking about this more, I think I should shorten the wording of my request to "Please consider enhancing nearblack so that the output bordering areas have the NODATA flag set." because in actual fact for my purposes being pure black or white is a poor man's nodata, a means to be able to easily ignore them.

I wouldn't want to break nearblack for someone else though. Frank perhaps you could elaborate on the part(s) which make you nervous? I can't think of a circumstance at the moment where having cells as nodata instead of black/white might be a problem.

My aim is to streamline the process I'm currently using which is time and disk space intensive: 

:: Get rid of all pure-black by setting it to black+1.
gdal_translate src-image.tif xx-noblack.tif -scale 0 255 1 255

:: Run gdal's nearblack to turn all border values within 15 of 0 to 0
nearblack xx-noblack.tif -o xx-borderblack.img

:: and now set pure black to nodata
gdalwarp -srcnodata 0 -dstnodata 0 xx-borderblack.img xx-nodata-edges.tif 

:: and compress
gdal_translate -co compress=lzw xx-nodata-edges.tif final-out.tif

12/16/07 04:22:02 changed by rouault

  • milestone changed from 1.5.0 to 1.6.0.

Postponed as the need expressed in this ticket is maybe a bit too particular for nearblack typical use case.