[gdal-dev] Border slivers and JPEG2000 compression

Smith, Michael Michael.Smith at maine.gov
Thu Dec 18 10:19:47 EST 2008

I tried that but it doesn't seem to write to JP2KAK.  If I do this:

nearblack mosaic_jp2.jp2

I get this error:
0...10..ERROR 6: WriteBlock() not supported for this dataset.
ERROR 1: GetBlockRef failed at X block offset 1, Y block offset 19
ERROR 6: WriteBlock() not supported for this dataset.
ERROR 6: WriteBlock() not supported for this dataset.
ERROR 6: WriteBlock() not supported for this dataset.
ERROR 6: WriteBlock() not supported for this dataset.

I have also tried creating an alpha channel with this:
gdalwarp -srcnodata 0 -dstalpha *.tif mosaic.tif
gdal_translate -ot Byte -of JP2KAK mosaic.tif mosaic_jp2.jp2

That works, but provides a JP2 that is twice the size since it has a
second band (these are black-and-white images, so one 8-bit band).  I
tried converting that to a single-band image, hoping it would interpret
the alpha channel correctly, with this:

gdal_translate -ot Byte -of JP2KAK -b 1 -a_nodata 0 mosaic_jp2.jp2

But the output again has a bunch of pixels on the edge which are now not
value 0.

I cannot gdal_rasterize -burn the JP2 because gdal_rasterize does not
write JP2KAK (why is that?  gdal_translate will but not gdal_rasterize)?

It seems like all the functions I need to work only do so on TIFFs, but
it's the JP2s I need it to work on.

Any other suggestions?  Some trick involving alpha channels I don't
know?  A way to get gdal_rasterize to write JP2KAK?

Michael Smith
State GIS Manager
Maine Office of GIS 
-----Original Message-----
From: Matt Wilkie [mailto:matt.wilkie at gov.yk.ca] 
Sent: Tuesday, December 16, 2008 1:50 PM
To: Smith, Michael
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Border slivers and JPEG2000 compression

Hi Micheal, try the nearblack utility (which is a relatively new 
addition): http://www.gdal.org/nearblack.html

"This utility will scan an image and try to set all pixels that are 
nearly black (or nearly white) around the collar to exactly black (or 
white). This is often used to "fix up" lossy compressed airphotos so 
that color pixels can be treated as transparent when mosaicing."


matt wilkie
Geographic Information,
Information Management and Technology,
Yukon Department of Environment
10 Burns Road * Whitehorse, Yukon * Y1A 4Y9
867-667-8133 Tel * 867-393-7003 Fax

Smith, Michael wrote:
> I have several orthophotos which are TIFFs, and they align with the
> quadrangle corners, which means they are rotated slightly, leaving
> uneven slivers along the edges where pixel value is 0 (the data for 
> these are available from adjacent tiles).  All the pixels inside the 
> 'real' area of the photo are value > 0.
> This is no problem with TIFFs, as the 0 can be turned off in 
> applications such as ArcGIS or serving them out via MapServer WMS.
> when I convert to JPEG2000 (using Kakadu), the edge pixels are 
> interpolated to different values, typically something like 0, 1, 2, or

> 3.  Thus I can't just filter them out. Also inside the photo,
> very dark pixels (which should really be value 2, 3, etc) are
> to value 0.  Thus they show up as 'holes' in applications when pixel 
> value 0 is filtered out.
> What I want to do is simply show a bunch of JP2 tiles, with the border

> pixels staying as value 0, and no other pixels having value 0.
> I have tried a couple approaches, including
> gdal_translate -a_nodata 0   (the border pixels still have values > 0)
> gdal_rasterize -i -burn 0    (won't write JP2KAK)
> Surely I'm not the first to try this, but I can't find the right steps

> on the web.  Any suggestions would be appreciated.
> **********
> Michael Smith
> State GIS Manager
> Maine Office of GIS
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

More information about the gdal-dev mailing list