[gdal-dev] Border slivers and JPEG2000 compression

[Matt Wilkie]

Hi Micheal,

I'm afraid I misadvised you. Nearblack and gdal_rasterize can't write to 
file formats which don't allow updating in place. Is using jp2 a hard 
requirement? Have you tried the available geotiff compressions 
(http://www.gdal.org/frmt_gtiff.html look at Creation Options)? Black 
and white images should compress pretty well.


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
http://environmentyukon.gov.yk.ca/geomatics/
--------------------------------------------


Smith, Michael wrote:
> 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
> mosaic2_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."
> 
> cheers,
> 
> 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
> http://environmentyukon.gov.yk.ca/geomatics/
> --------------------------------------------
> 
> 
> Smith, Michael wrote:
>> I have several orthophotos which are TIFFs, and they align with the
> USGS 
>> quadrangle corners, which means they are rotated slightly, leaving
> small 
>> 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.
> But 
>> 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,
> sometimes 
>> very dark pixels (which should really be value 2, 3, etc) are
> converted 
>> 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
>