Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#3777 closed defect (fixed)

BSB files with missing value for last column cannot be color-expanded into RGB

Reported by: vadp Owned by: warmerdam
Priority: normal Milestone: 1.8.0
Component: GDAL_Raster Version: 1.7.2
Severity: normal Keywords: bsb vrt rgb


A certain BSB chart (see attachment) produces a clipped raster after being converted to expanded .vrt with gdal_translate and then warped with gdalwarp.

Here is how to reproduce this:

$ gdal_translate -of vrt 2028B01.KAP 2028B01.KAP.vrt
$ gdalwarp -of gtiff 2028B01.KAP.vrt 2028B01.KAP.vrt.tif

The result is fine.


$ gdal_translate -expand rgb -of vrt 2028B01.KAP 2028B01.rgb.vrt
$ gdalwarp -of gtiff 2028B01.rgb.vrt 2028B01.rgb.vrt.tif
Creating output file that is 8022P x 13980L.
Processing input file 2028B01.rgb.vrt.
0...10...20...30...40...50...60...70..ERROR 1: No entry 255.

The result is clipped at the lower edge.

Change History (4)

comment:1 by vadp, 14 years ago

The file is too big to be uploaded directly into the ticket. Here is a download link to it:

comment:3 by Even Rouault, 14 years ago

Keywords: gdalwarp removed
Milestone: 1.8.0
Resolution: fixed
Status: newclosed
Summary: gdalwarp produces a corrupted raster from a rgb expanded VRT fileBSB files with missing value for last column cannot be color-expanded into RGB

The issue is that there's no pixel value for the last column of the BSB. This occurs sometimes in some BSB charts for some unknown reason. See bsb_read.c around line 842:

/* -------------------------------------------------------------------- */
/*      For reasons that are unclear, some scanlines are exactly one    */
/*      pixel short (such as in the BSB 3.0 354704.KAP product from     */
/*      NDI/CHS) but are otherwise OK.  Just add a zero if this         */
/*      appear to have occured.                                         */
/* -------------------------------------------------------------------- */
        if( iPixel == psInfo->nXSize - 1 )
            pabyScanlineBuf[iPixel++] = 0;

I've fixed bsbdataset.cpp in r20811 so that it doesn't not transform the fake color entry 0 into 255, but keep it as 0.

Workaround without the fix: remove the last column by specifying -scrwin when using gdal_translate

gdal_translate -expand rgb -of vrt 2028B01.KAP 2028B01.rgb.vrt -srcwin 0 0 14618 3940

comment:4 by vadp, 14 years ago

Great! I've implemented a workaround in my script as per you suggestion. Thanks rouault!

Note: See TracTickets for help on using tickets.