Gdal Bug? was: Re: [gdal-dev] JP2MRSID Issues

[Stephen Woodbridge]

As a follow up on this issue, if I remove the -of VRT on the 
gdal_translate it will create a geotif and then ALL the tiles are 
extracted without any errors. So this looks like a bug in gdalwarp or in 
the JP2MRSID driver since the jp2 can be converted to a geotif without 
errors and gdalwarp will work with it, but has trouble when you try to 
extract sub-zones from the jp2 image.

Currently, I only have 500MB jp2 files to work with, I will look through 
the files and see if I can find a smaller one that exhibits the same 
behavior.

Does anyone else have any of these large county composite jp2 images 
that they can try and confirm this issue with?

-Steve

Stephen Woodbridge wrote:
> Hello,
> 
> I posted this buried in another thread and thought it should be reposted 
> in its own thread. A short history, I have a lot of USDA county 
> composite DOQQs that have been assembled into JPEG2000 files that are 
> about 500MB each. I am trying to chop these back into DOQQ GeoTiffs. I 
> have a script that does the chopping, it just automates the process and 
> issues commands to do the work.
> 
> I have abandon using the JPEG2000 driver and an now using the JP2MRSID 
> driver. This is working better, but I'm still having problems like this:
> 
> I create a VRT file as follows for each jp2 file:
> 
> mkdir -p /home/swoodbridge/tiler-tiffs/30430-1226332146/src
> gdal_translate -of VRT 
> /var/data/raw_data/minnesota/ortho_1-1_1m_j_mn161_2008_1.jp2 -b 1 -b 2 
> -b 3 /home/swoodbridge/tiler-tiffs/30430-1226332146/src/tmp.vrt
> 
> then the VRT file is iterated over to extract the tiles with commands like:
> 
> gdalwarp -srcnodata 0 -dstnodata 0 -s_srs +init=epsg:26915 -t_srs 
> EPSG:4326 -te -93.5 43.8125 -93.4375 43.875 -rb -wm 250 --config 
> GDAL_ONE_BIG_READ ON -co "TILED=YES" 
> /home/swoodbridge/tiler-tiffs/30430-1226332146/src/tmp.vrt 
> /home/swoodbridge/tiler-tiffs/30430-1226332146/B-93_43/B-93_43_041.tif
> 
> gdalwarp: ../compressed/compressed.cpp:1724: bool 
> kd_tile::read_tile_part_header(): Assertion `tpart_body_length >= 0' 
> failed.
> Creating output file that is 6029P x 6029L.
> 
> This does not happen on all image tiles that I try to extract, but does 
> happen on a significant number of them like nearly 50% in one case. I 
> looked at the pattern of failures and it looks like failures happen 
> within a row of the jp2, so extracted tiles are G=good, X=bad, .=empty
> 
> ................
> ..GGGGGGGGG.....
> ..GGGGGGGGG.....
> ..GGGGGGGGG.....
> ..GXXXXXXXG.....
> ..GGGGGGGGG.....
> 
> 
> ..GXXXXXXXG.....
> ..GXXXXXXXG.....
> ..GXXXXXXXG.....
> ..GXXXXXXXG.....
> ...GXXXXXXXG....
> ................
> 
> Any thoughts on this?
> Is there a way to verify its compression integrity?
> 
> I have try two different jp2 files of the 300+ friles that need to to be 
> chopped up and gotten similar results.
> 
> Thanks,
>   -Steve
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev