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

[Stephen Woodbridge]

Frank, anyone,

Thoughts on this issue?
Thoughts on how to better diagnose the issue?
I can talk to the client about making an image available to someone if 
that would help.

I'm totally stuck on this one, converting 300+ images to tif first at 
2-3 hours per image is not going to hack it.

Thanks,
   -Steve


Stephen Woodbridge wrote:
> 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
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev